Re: Generics vs. Message passing: object namespaces

On 22 Feb 2007, at 10:26, Tom Locke wrote:

> I may well have missed it, but in all this talk of generic-function  
> based OO vs. message-passing OO, what about the issue of namespaces  
> scoped to objects.
>
> e.g.
>
>     buffer.append(x) vs. append_to_buffer(buffer, x)
>
> 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. Maybe someone will pull me up on this  
> particular example, but one only has to take a look at any CLOS or  
> Dylan code to see that the issue is real.
>
> To my mind one of the chief benefits of the OO style is in  
> organisation of code. We put things in places that makes sense, and  
> we find them easily later. Yes this breaks down if a method belongs  
> equally in two places, but it's still a big net win IMO.
>
> In message-passing style OO, it's often possible to simply guess  
> the method name, and there is often support in the editor for  
> enumerating the available methods. So writing is easier. Reading is  
> easier too - that "_to_buffer" in the above example is largely  
> noise. Noise that adds up pretty quickly.
>
> I wonder if language designers, with their theoretical bent, find  
> this issue of little importance - to a mathematician, a name is  
> just a name. As long as it is distinct, what else matters? To us  
> humans, it matters a lot!
>
> As I said - maybe this issue did already get raised -- maybe in  
> language too fancy for me to notice ;-) Either way, from a  
> pragmatic point of view, I'd say this is issue numero uno, so some  
> extra clarity would be very interesting.
>
> Proponents of CLOS - what say you?

That's an issue of namespace management, and orthogonal to whether  
you use a generic function approach or a message sending approach.

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. [Think append(buffer, x) and  
ll.discuss.Buffer.append(buffer, x) in more orthodox languages. ;) ]

Many message-sending style OOP approaches provide some form of  
namespace management as well, so the issue seems to come up sooner or  
later anyway, independent of programming style.

I think it's problematic when the same language construct is  
overloaded with many different duties (as a basis for namespace  
management, the type system, dynamic dispatch, access control, and so  
on). This tends to make each ingredient less flexible than necessary  
due to compromises with the not necessarily compatible semantic  
issues of the other ingredients.


Pascal

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