Re: Generics vs. Message passing: object namespaces

On Feb 23, 2007, at 4:49 AM, Pascal Costanza wrote:
> On 23 Feb 2007, at 01:47, Randall Randall wrote:
>> On Feb 22, 2007, at 7:17 PM, Pascal Costanza wrote:
>>> On 23 Feb 2007, at 00:14, Tom Locke wrote:
>>> 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.
>>
>> But these should accomplish different things.  Regular functions
>> need to be kept separate, but generic functions need to be folded
>> into the same name in the namespace you're using them in, unless
>> there's some specific reason the programmer doesn't want to do that.
>
> I don't quite follow you. The only difference between functions and  
> generic functions is that functions are defined in a single place  
> whereas generic functions can have distributed definitions. This  
> means that you need access to some namespace when you want to call  
> a function from that namespace - and this is the same for functions  
> and generic functions. Additionally, you may need access to some  
> namespace when you want to define methods on a generic function  
> from that namespace. But that's the only difference here.
>
> It may be important to stress that methods are essentially  
> anonymous. Only the generic functions that contain them have names.  
> (In a Scheme-style language, even the generic functions are  
> anonymous and are simply bound to variables, so in such languages  
> this all boils down to having a good modularization mechanism for  
> plain variables.)

While I understand that the CL package system doesn't
actually do this, I would prefer that weapon:draw and
pen:draw both be accessible as (draw ...) in the package
in which I'm using them.  If they have some actual
conflict in the method signatures, then that's a compile
time error, but if they don't, keeping two separate names
seems like it defeats much of the utility of generic
functions -- especially "very" generic ones like length.

So, while normal functions have to be disambiguated with
a package qualifier or explicitly renamed, generic functions
which have methods whose signatures don't conflict are
easily thought of as a single conceptual generic function,
and should be combined in using packages by default.  In
my opinion. :)


--
Randall Randall <[email protected]>
"[W]e ARE the market, this IS the market working, there's nothing
  external to be deferred to." -- Ian Bicking, on "let the market  
decide"