> I'm reading about the proxy design pattern in Chamond Liu's
> "Smalltalk, Objects, and Design".  (Good book!)  On page 227 he talks
> about the Ghost variant of a proxy.  In his example, the proxy is for
> a Customer object.  The proxy overrides doesNotUnderstand:.  When it
> gets a message it doesn't understand, it creates a Customer, changes
> itself into a Customer, and then redispatches the message.  Here's the
> code.
> 
> doesNotUnderstand: aMessage
> |customer|
> customer := "materialize the customer".
> self become: customer.
> ^aMessage sendTo: self.   "redispatch!"
> 
> I have two questions which I suspect might be naive.
> 
> 1.  Why isn't the last line simply
> 
> ^self aMessage

Let's start with the question, what is a message? A message
consists of a method selector and 0 or more arguments. When
we write Smalltalk source text we typically type in the name
of the object to receive the message (ie self) followed by
the selector and arguments suitably arranged. Most of the time,
a message object is never created. Instead the compiler and vm
have been optimized to dispatch the message as expediently
as possible. In the event that the message cannot be dispatched,
the message is instantiated as an instance of the class Message
in order to record the selector and argument information that
define the message that could not be sent.

Consider the following

    self xlerb

It is unlikely that the object receiving the message will understand
the message selector, #xlerb. If it is not found, the vm will
arrange to create an instance of Message with the selector, #xlerb,
and an empty collection of arguments. The vm will then send the message

    self doesNotUnderstand: <a new Message object with selector #xlerb>

to the original receiving object.

We note that the argument, aMessage, is an instance of the class Message
holding the offending selector and any supplied arguments. What aMessage
is not, is text that the compiler will know how to handle. The compiler
will look at the text 'self' and figure out that it is referring to
an object that should receive the following message. It will see the
text 'aMessage' and treat that as a method selector, not the message
object that that holds the selector that I really wish to send.


> 
> Doesn't this do the same thing?
> 
> 2.  If there's a good reason for doing it as originally stated, how do
> you do this in Squeak?  I wasn't able to find a sendTo: method
> using the method finder.

Try looking for the message, #sentTo:

> 
> Rick Zaccone
> -- 
> zaccone at bucknell.edu
>