🚀 go-pugleaf

Peter Hinely wrote:
> 
> In article <3176B6C5.F4D@concentric.net>,
> Alan L. Lovejoy <alovejoy@concentric.net> wrote:
> >
> >The central point of object-oriented programming is...objects.  That is,
> >the unification of value and behavior into an encapsulated object.
> >
> >--Alan
> 
> Behavior (implemented as methods) need not be encapsulated into objects
> for a language to be object-oriented.  This corresponds to real life where
> most objects do not have methods encapsulated into them.  Does a ball know
> how to throw itself?  No, it is thrown by something else.  This can be
> modeled in a language via generic functions which dispatch to the
> appropriate method according to the argument list passed to it.
> 
>   throw( <ball> )
>   throw( <something-else> )

It's true that a ball would not generally be responsibile for throwing
itself.  But it's also true that not all message sends are to "self."
Who throws the ball or sends the message isn't the point.  The question
that matters is this: who or what is responsible for determining the 
reaction to being thrown or receiving a message? 

The reaction of a ball to being thrown is determined by its nature,
by what it is.  You can see this if you try throwing something really
different, such as air, neutronium, negative matter or a Russian
verb declension.  All these things react differently to being thrown.

The unification of value and behavior into an encapsulating object is
not necessarily a physical encapsulation.  It only needs to be a logical
encapsulation. If the object that is thrown, or the object that receives 
a message, affects what happens as a result then its behavior is
logically encapsulated.  

A value is an object not because it **contains** its behavior, but 
because its behavior is a function of its identity (not necessarily its
class, e.g., Self).  What matters is the fact that applying the "same" 
function with arguments of different types/classes results in different
behavior. The mechanisms that make that possible are irrelevant.

Self stores methods in slots of the object itself--directly mapping
an object to its behavior.  Smalltalk stores methods in the class, which
is stored in a hidden slot of the object--indirectly mapping an object
to its behavior. Generic method systems rely on the method dispatch 
mechanism to associate argument lists (by type or class, statically or
dynamically determined) with the appropriate method--also an indirect
mapping of objects to their behavior.  The end result is mathematically 
equivalent--except that the generic method technique apparently handles 
multiple dispatching better.

--Alan