Re: Generics vs. Message passing: object namespaces

On 23 Feb 2007, at 18:42, [email protected] wrote:

> 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.

Here is the problem. Consider two interfaces in Java:

interface I1 {
   int foo(int x);
}

interface I2 {
   String foo(int x);
}

class C implements I1, I2 {

   public int foo(int x) {return 0;}

   public String foo(int x) {return "";}

}

This doesn't compile. There is no way in Java to define a class that  
can implement both I1 and I2. If I1 and I2 are from different vendors  
and you need to implement both interfaces, you're screwed.

However, if the method signatures are compatible, things can get even  
worse:

interface HasBlood {
   void draw();
}

interface HasGun {
   void draw();
}

class Person implements HasBlood, HasGun {
   ?!?
}

So the actual issue is not whether you can distinguish between  
gun.draw and blood.draw. The issue is whether you know what happens  
when you say person.draw - does this mean that the person in going to  
draw a gun, or that blood is going to be drawn from that person?

In other words, you need some form of namespace management to be able  
to distinguish such cases. My guess is that people typically just  
switch to longer names, like person.drawBlood vs. person.drawGun, and  
that's exactly the same solution as saying (draw-blood gun) vs. (draw- 
gun person). This is, in other words, just a case of "manual"  
namespace management.

That you need namespace management and what your actual namespace  
management system looks like if you have one is independent of  
whether you have OOP based on message sending or on generic functions.

That you rarely encounter naming issues with message sending may just  
mean that you intuitively know how to avoid them in the first place.  
I find it hard to tell whether I am intuitively avoiding naming  
issues or not when I am programming in Common Lisp. So I don't know  
how to honestly answer the question whether naming issues occur more  
often with generic functions than with message sending. I just can  
give the subjective impression that I have never had any serious  
issues with this in Common Lisp.

And to paraphrase something that Joe Marshall said elsewhere some  
time ago: The only thing I know for sure about 90% of all programs is  
that I haven't seen them.

> DING!  I declare this round goes to object dispatch.

This is juvenile. I don't want to win a fight, and I couldn't care  
less whether you are going to use generic functions or not.

To me, generic functions provide a serious increase in expressive  
power and make my life a lot easier. Some tedious design patterns and  
idioms simply disappear because of them, especially the Visitor  
pattern. It's such an improvement wrt programming convenience that I  
probably wouldn't mind the naming issue even if it were real.

I have used both OOP systems extensively in the past, there is no  
question for me anymore. I can't tell whether it has the potential of  
becoming your preferred choice, but I can explain the advantages and  
trade offs that I see.


Pascal

-- 
Pascal Costanza, mailto:[email protected], http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium