Collection do: aMessage (was Re: (f value: n) <=> f{n})

Brent Pinkney Brent at astarte.co.nz
Mon Jul 10 21:16:09 UTC 2000


> I have been playing around with "restoring" the importnace of Messages in
> Squeak. I recall reading once that someone (Dan?) said that the only thing
> you ever do in Smalltalk is send an object a message and get an object
back.
> 
> I took this to mean that CompiledMethods, byte codes, primtives, inlining
> conditionals, etc. are all just artifacts which implement this notion in a
> way which gives reasonable performance.
> 
> Attached is a changeset which
> 1. Removes class MessageSend 

Why? It has useful functionality (partial messages with receiver).

Ah -is that why it is there ? But Surely it is just as easy to copy an
existing Message instance and resend it with a new reciever in the (few)
occasions you need different receivers ? I find it terribly daunting to get
into a system when there are lots of little classes with little semantic
difference.

Where too is the benefit of sending same MessageSend instance to multiple
recievers if the message expects arguments which are modified by the
execution ?

...

I much prefer

  #(2 4 6 8) do: #factorial

So do I. Alas that means that every implementor of #do: aBlock would have to
ask the argument to convert itself to a MonadicValuable (in ANSI parlance).

ie. something like:

#do: aMonadicValuable

	1 to: self size do: 
		[ :i | aMonadicValuable asMonadicValuable value: (self
elementAt: i) ].


It is trivial to add Symbol>>#asMessage but it is of not use unless it gets
called. This is a general problem I am running into. 

I am hoping to attack it by allowing a compiled method to refer to an
instance od Protocol (my class) to determine the parameters expected by the
message, attempt a conversion and retry. (FYI. That is why MessageSend was
removed in the changeset)

Brent





More information about the Squeak-dev mailing list