Re: Generics vs. Message passing: object namespaces

> On 2/23/07, [email protected] <[email protected]> wrote:
>>
>>    No.  Object1.foo and object2.foo select two entirely unentangled
>> entities with object dispatch, if object1 and object2 are unrelated.
>> Smashing *unrelated* methods together that happen to have the same
>> name into a single entity is deeply wrong, conceptually, and bound to
>> cause real problems in the real world as well.
>
> Nonsense!  We are selecting a function based on two data: the runtime type
> of the value of Object and the literal name `foo'.  The space of denotable
> methods is Type * method-name.  How this is implemented is irrelevant.
> Whether you have a table per type where each method is an entry in the
> table, or if you have a table per method indexed by object type makes no
> difference.

    Yes, the internal implementation is not relevant, but neither was I
referring to implementation.  In CLOS, one defines a generic function
then specific implementations of it for particular types.  Both
internally *and* in the user-visible model, there is an entity called
'foo' (the generic) with multiple methods (the specifics).  They share
a function signature.  The authors of the disparate methods sharing
the name presumably also share an idea of what it should do.  Thus
there is a relationship between the objects sharing the generic. 
Exactly analogously to the object-centric idea of sharing a base
method among derived classes.  But the generic dispatch approach
obviously works a bit differently, name-wise, and therein lies the
rub.

    Of course this sharing is exactly what you don't want if the objects
truly are not related and do not want to share a conceptual function
or an actual function signature.  Of course this kind of collision is
what the package system was created to resolve, and it does so.

    But the same collision wouldn't happen in the first place with object
dispatch.