Re: Generics vs. Message passing: object namespaces

On 2007 Feb 24, at 12:13 AM, [email protected] indited:

>> We seem to be at an impasse. You seem to be insisting that object
>> based dispatch scales "better" and that generic dispatch has to be
>> without any name space control and so doesn't scale. And "we" are
>> unsuccessful at convincing you to let go of the local maxima of
>> object based dispatch for a much more powerful mechanism , and the
>> issue seems to be unconvincing because you have to deal directly with
>> the name space issue.
>
>     There are so many misunderstandings and misrepresentations in your
> post, I am daunted by the task of correcting them collectively.
> Suffice it to say I do not believe what you think I do.  If you are
> interested at all in my actual position, please re-read the prior
> posts on this thread where all has been said before.


Let's see, would that happen to be:

> On 23 Feb 2007, at 2:23 PM, Pascal Costanza wrote:
>> Sooner or later, the libraries of some language will grow bigger, and
>> then sooner or later, you need objects that adhere to incompatible
>> interfaces (messages that happen to have the same name but are  
>> used for
>> different purposes). You can then either choose to distribute the
>> functionality across several objects, and get object identity  
>> problems
>> along the way, or you can choose to incorporate proper namespace
>> management.
>
>     This is a weak argument, because that point is 'sooner' with
> CLOS-style generics and 'later' with OO namespaces.  You can argue
> that many OO languages lack 'proper' namespace management, that is, a
> single elegant solution that solves everything, but if this lack shows
> up further on the scaling path than in CLOS, it indicates that the
> modularization provided by objects may not be perfect but it *is* a
> partial solution that may be good enough 90% of the time.  It may also
> be possible to extend or enhance the system to be a 'proper' one --
> the idea may not be a mistake that must be undone with a completely
> different system.  But the semantics of object dispatch seem to mostly
> solve a problem that in a CLOS-like world require appeal to a second
> mechanism.

The whole mess in C++ as highlighted by the '<<' and '>>' operators  
is a pretty clear indication that it is a mistake.

>     You can also put aside pragmatics and argue that providing  
> namespaces
> automatically with objects is a natural and desirable feature.
> Scoping to the object may not always be the right thing to do (and
> thus may be overused) but it is hard to imagine that it is not
> generally useful.

And has been pointed out "earlier in the thread", you can do single  
method dispatch, it is a proper subset, so desire it away, just  
because you can do multiple parameter dispatch doesn't mean you  
always have to.


So again, just because you can call 'image:draw' with  
'image_instance.draw' and 'hoslter:draw' with 'holster_instace.draw'  
doesn't alleviate the need for you to know which class hierarchy's  
draw you are intending to invoke. generic dispatch is strictly more  
powerful than object(single parameter) dispatch. You get a little bit  
of gain (for a while) from apparently free name space management, but  
the complexity problem isn't about having to type a class-heirarchy  
qualifier to indicate which brand of 'draw' you want to invoke, it is  
all about having multiple brands all in scope at once.

--Doug