Re: Generics vs. Message passing: object namespaces

> If you need to have both 'draw' generics you then rename them on
> import when defining the module so they are distinct.

Which is precisely the problem - I can't have picture.draw, gun.draw  
and curtains.draw in the same source file, even though, as a human  
reader, that would cause me no difficulties whatsoever. Rather, it  
makes the code much easier to read.

Dave Roberts:
> When I first encountered CLOS, coming from
> a standard C++ -> Java background, it seemed downright strange. ...  
> Having worked with CLOS more now, I really appreciate the CLOS model.

The points you've raised are not in question - the generic function  
approach undoubtedly yields a lot of expressive power. I'm just  
asking if the price is a loss of nice method names, or is there a  
best of both worlds solution?

Joe Marshall
>> I believe I am correct in stating that the generic function style
>> requires the latter? Sharing a single generic function "append" among
>> the very wide range of objects that might provide a definition isn't
>> workable.
>>
>
> Why not?
>
> The usual implementation of this sort of thing is a table of  
> methods... [snip]

I was talking about semantic issues not operational ones. The draw  
example above is a better one, where the same name has various  
unrelated meanings depending on context. I think differing arity is a  
particular problem?

Joe again:
>> CLOS and Dylan do in fact suffer from type-name-in-the-method-name
>> syndrome do they not?
>>
>
> Not if they are done correctly.

Would you like to elaborate?

Pascal:
>>> With a good module / package / type system, you can say (append  
>>> buffer x) when it's unambiguous what you mean, and (buffer:append  
>>> buffer x) when it's not.
>>>
>>
>> Does "good" mean better than anything we currently have in a  
>> production-grade language?
>>
>> CLOS and Dylan do in fact suffer from type-name-in-the-method-name  
>> syndrome do they not?
>>
>
> The simplest answer I can think of is this: Generic functions are  
> just functions, so any approach that solves namespace management  
> issues well for function names is automatically also good enough  
> for generic function names.

The simplest answer, it seems, is not always the clearest! So far no  
one has disputed that real-world Dylan and CLOS do actually have this  
problem. Why is your "good enough" solution absent?

Tom