Brent Pinkney <Brent at astarte.co.nz> wrote:
> Hi,
> 
> 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).

> 2. Enhances Message with a receiver instance variable (ie. same as
> MessageSend)

But the same message should be able to be sent to different receivers.
MessageSend on the other hand has partial information including the receiver.
To me a message is that which is sent, it does not include the receiver.

> 3. Implements #value:

Good.
> 
> Thus it is possible to do the following:
> 
> #(2 4 6 8) do: (Message selector: #factorial)
> or
> #(2 4 6 8) do: #factorial asMessage

I much prefer

  #(2 4 6 8) do: #factorial

to this. Since, as you say, message sending is important there shouldn't
be unnecessary typing surroundig this. The importance of messages is
not manifested by typing 'message' over and over, its importance is
manifested by being built into the language.

I think it is better leave this arranged as is. (Adding a few value:-messages)

> It is also possible to preset the argument....
> ws _ WriteStream on: String new.
> p _ Message selector: #printOn: argument: ws.
> #(2 4 6 8) do: p.
> ws contents.

or

  (#(2 4 6 8)
    inject: (WriteStream on: String new)
    into: #print:)
    contents

This looks strange at first I guess, but I think you can learn to like
it.

/Mats