I think the nub of your confusion is twofold. The method #at:put: is a keyword method and it isn't right to think o them as two keys. It is one compound key and unlike most every other system, Smalltalk keyword message sends allow the programmer to name each argument. This is very fine indeed.

The other item is in your thinking that these methods are defined in a prototype chain, like JavaScript. Primarily Smalltalk is a class-based inheritance system for method lookup on message send. What I mean by your example is that when the message #at:put: is sent, the system will start with the concrete class in question, Array, and attempts lookup of #at:put:. When this fails, it then traverses the lookup to the superclass (->ArrayedCollection) and so on on lookup failure (->SequenceableCollection ->Collection ->Object) and at the Object class, the lookup into that Class's methodDictionary succeeds. It tuns out that Object>>#at:put: is a primitive in the vm (#61) that is able to store into an Array object, a variable class and indexable, by the way. Consider the method Array>>atWrap:put: also calling primitive 61.

This may help with foundations: http://samizdat.cc/shelf/documents/2004/08.02-historyOfSmalltalk/historyOfSmalltalk.pdf

I hope this helps.

On 10/16/2016 12:44 AM, CodeDmitry wrote:
I understand that it is a single message send, but to know how to handle the
message at runtime, the parser needs to somehow determine where the
implementation of that message is. It must do a lookup based on multiple
keys(at, and put), which is really confusing. "methods" are easy to look up
because they only have one name, but messages have one name which is split
amongst each argument.

Simple concatenation does not make sense, since {at: x, put: y} and {a: x,
tput: y} are different messages.

The only way I can think of this being implemented "easily" is by storing a
table of entries {num_args, arg_names, impl_ref}, and then have the function
"send" do a linear search over this table until it finds an entry with
num_args = 2, each arg_name matching the argument name keys in order, and
then calling the impl_ref with the array of values without the names.

I'm wondering if there is a way to do this without having to loop over every
single message the object has, then every message its' parent object has,
and so on, just to find which function you actually want to call.

View this message in context: 
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Reply via email to