On Wed, 2004-09-29 at 18:51, David A. Black wrote:

>   a = Object.new
>   def a.meth; puts "hi"; end
>   a.method("meth").call      # hi
> 
> At no point has the message "meth" been sent to the object a -- but
> "meth" is still the method's name.


     I'm not sure I agree with this.  Of course, at one level it is
tautologically true; there is no "object" a and no "messages" are ever
really sent--instead, the whole thing is being simulated by a clever
arrangement of silicon, copper, etc.  But if you accept that we are
talking at some level of abstraction from the hardware, enough so that
the analogy of objects and messages works, you are claiming your code
snip does something like this:

      * Send Object the message ["new"]; call it's reply a
      * Send the message ["def","meth",{ || puts "hi"}] to a--this has
        the effect of telling a what to do when it gets the message
        "meth".
      * Send a the message ["method","meth"] to a, and hold the
        result--this is in effect asking a "what would you do if you got
        the message 'meth'?"
      * Send the result of the last step the message ["call"]--in
        effect, saying "do your thing"

     If you anthropomorphize the process as I've outlined it, clearly
the object a never gets the message meth.  If I asked you "what do you
do when your mailbox is full?" and then logged in as you and did exactly
the steps you specified, it would _not_ be the same as telling you "your
mail box is full."

     But I would have to log in as you for the analogy to work.  And
what if the process required more than just your log in--what if it
included things like "I'd make a humorous entry in my blog"--so I'd have
to be able to write like you, etc. as well.  In fact, it is easy to see
that I might have to _be_ you, for all intents and purposes to care this
off successfully.  This analogy maps directly back to you example code. 
The method returned and subsequently called executes _as_a_method_of_a_,
with all the context, access rights and restrictions, etc. that that
implies.

     So we could look at the last to steps in another in other way; for
example, as:

      * Send a the message ["method","meth"] to a, and hold the
        result--this is in effect asking a "what would you do if you got
        the message 'meth'?"
      * Send the result of the last step the message ["call"]--in
        effect, saying "send yourself to a with instructions to execute
        you (not in the Rozencranz & Guildenstern sense of course)".

     No, we still don't have a receiving the message "meth"; instead, we
have it looking up what it would do if it did get the message, and then
doing it.  But what happens when an object gets a message?  Doesn't it
do exactly these two thing, in this order?  So the only difference
between this case and "receiving the message 'meth'" is that in your
example the process is interrupted (potentially indefinitely) while the
caller gets a chance to do stuff.

     So, how is this different than what happens in a threaded
application?  Should we say that a threaded OOapp works by passing
message, unless a context switch occurs at a certain point, in which
case we use another metaphor?

     Or should we say that your example is a case of the object a
receiving the message "meth", but suspending control (as, say, an
iterator does with a yield) in mid stream?

     As you can see, I'm not sure I agree with your example.

     -- MarkusQ