Re: Generics vs. Message passing: object namespaces

>> And not knowing the type isn't just an unwanted side-effect, it's  
>> actually the goal. Dynamic OO is about escaping from fragile and  
>> inflexible type dependencies by using type independent messages  
>> instead of type dependent functions.
>
> You still haven't told us how you disambiguate the draw message  
> when your object inherits both from a weapon and a picture.  
> Especially when both draw messages have the same signature.

If there is type information associated with the *reference*, not the  
object, e.g. as in a statically typed language, this can be used to  
disambiguate. C# does this.

Dynamically typed languages do indeed run into a problem. As you  
pointed out you will have to use something along the lines of an  
adapter object, and yes, run into object identity worries.

It is conceivable that you could run into a big problem if you face  
just the right interaction between multiple inheritance, polymorphism  
and object identity. In practice this seems to be extremely rare. Is  
this a big enough deal to dismiss object-dispatch in dynamically  
typed languages? I'd say no, but that's more of a judgement call than  
an absolute.

What I wish I was more clear on, was how often, in GF based OO, one  
ends up using names that object-dispatch people would consider overly  
verbose, whether it be draw-gun at the definition site, or gun:draw  
at the call site.

Answer: all over the place => big win to object-dispatch

Answer: very rarely => big win to GFs

(note to black-and-white types: I did not say "overall win to ...")

The reality is probably in between, and maybe only a lot of  
experience with both styles would shed light (combined with a  
detached state-of-mind!).

I think this is a big reason why language design is such a mysterious  
art - a deep understanding of the *pragmatic* reality of different  
styles is only possible with a lot of experience, and few people have  
the time to gain this experience in a wide range of paradigms. Kind  
of a mirror of Paul Grahams point that the only way to find out if  
someone is a good programmer is to work with them.

Tom

p.s. I'm very glad to see this thread survive a near fatal detour  
into flame-dom :-)