Hacker News Reader

Comment by Rochus | Hacker News Reader

"perform" is a method of the Object (i.e. Integer super) class, the argument is a symbol; this call just does a second method dispatch, i.e. "perform" does yet another dispatch on the Integer object and then calls the "factorial" method; so no, neither this is message passing; it's rather like Object.getClass().getMethod() and Method.invoke() in Java.

View on HN

huh? That makes no sense to me (I must be missing something here).

'perform' is indeed a msg. The integer object doesn't need a 'perform' method in order to do something with that call. Its entirely up to each object to decide how it wants to deal with a msg. Including those msgs for which there isn't a corresponding method.

In other words, the caller has NO way of knowing (or enforcing) what the object its sending a msg to, does with that msg. Eg: based on certain runtime conditions, an object can reconfigure itself at runtime, and simply proxy certain messages to another object, potentially running on a different machine, and relay the results back.

How is that not message passing?

Why should "perform" be a message? It's just a method of the Object class, which is the superclass of Integer. You can use my St80ClassBrowser and St80ImageViewer (see https://github.com/rochus-keller/Smalltalk/) to check the ST-80 source code and image if you want; there is a list of all selectors (i.e. method signatures) and the classes which implement them. Going up the class hierarchy when doing virtual method dispatch is a fundamental concept of all object-oriented implementations; in contrast to e.g. C++ this can be done dynamically at runtime in Smalltalk or Java (which is also called late binding). In contrast to Smalltalk in Java the class loader verifies that a method for the referenced signature actually exists; in Smalltalk you can try to dispatch any signature which can result in a call to the doesNotUnderstand method of the Object class; the same could also be achieved in Java with a custom class loader, but usually you want to avoid it.

I suppose it depends on how we define "true" message passing.

A general problem of human communication.

But there is also a pertinent body of knowledge that is taught and tested at universities, which includes an accepted terminology.

The relevant classes in the Smalltalk-80 source code are even called "CompiledMethod" and "MethodDictionary".

See also primitivePerformWithArgs, lookupMethodInClass and executeNewMethod in part 4 of the bluebook.

As a counterpoint, I would suggest looking at Jeff McAffer's CodA project. It defined a group of 7 metaobjects to define the behavior of each object, six of them for message passing and one for accessing state. He couldn't patch the commercial VisualWorks virtual machine and used #doesNotUnderstand: tricks to make his prototype work. It wasn't fast, but showed that the semantics were correct. Here are the message passing metaobjects he defined:

- Send: prepares a message to be sent and negotiates with the receiver

- Accept: negotiates with the sender

- Queue: can save accepted messages to be handled later

- Receive: deals with queued messages

- Protocol: can associated the selector in a message with executable code

- Execution: knows how to used system resources to actually do what the message asked

The default metaobjects are 100% compatible with Smalltalk-80 base level code but his thesis show several interesting alternatives.

There is no doubt that you can implement a message passing system in Smalltalk, as you can with any Turing complete language. In Smalltalk instead of "calling a virtual method" people just say "sending a message". But it actually works quite similar like e.g. the Java VM. Params and receiver object are evaluated and pushed to the stack, then the method is looked up in the receiver class using the selector (which is an internalized string) and then calls the method with the given parameters (this lookup and call is called "send" in Smalltalk); the major difference is that in Java the verifier checks whether a method with the given name and signature actually exists in the class when it is loaded; but also in Java you can influence the dispatch as you described and e.g. create your own class loader.

While you can implement message passing on top of any language, as you said, I was talking about doing message passing under Smalltalk-80.

There are non messaging parts in Smalltalk-80, like assignment. The Self variant of Smalltalk goes quite a bit further in using message passing for everything.

Well, if "true" message passing is not what Smalltalk-80 does, how will looking at Smalltalk-80 source code show us what "true" message passing is?

Do you mean like Erlang?

> how will looking at Smalltalk-80 source code show us what "true" message passing is?

Not at all; but you can look at the Smalltalk-72 source code.

> Do you mean like Erlang?

Examples of "true" message passing are e.g. SOAP or MPI. Erlang is an example where message passing is indeed part of the language; another example are Go channels.

My guess is that very few people care to learn anything about Smalltalk-72, and simply saying you mean something like SOAP or Erlang will clearly communicate what you mean by "true" message passing.

If your interest is point-scoring maybe say Smalltalk-80 is simulated message passing or faux message passing ;-)

>But there is also a pertinent body of knowledge that is taught and tested at universities, which includes an accepted terminology.

Well, speaking of universities, can you find a univercity-level course/book that doesn't characterize Smalltalk (post 76 too) as having message passing?

Reply on news.ycombinator.com