Re: Generics vs. Message passing: object namespaces

On 2/23/07, [email protected] <[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.  You can argue
> that many OO languages lack 'proper' namespace management, that is, a
> single elegant solution that solves everything, but if this lack shows
> up further on the scaling path than in CLOS, it indicates that the
> modularization provided by objects may not be perfect but it *is* a
> partial solution that may be good enough 90% of the time.  It may also
> be possible to extend or enhance the system to be a 'proper' one --
> the idea may not be a mistake that must be undone with a completely
> different system.  But the semantics of object dispatch seem to mostly
> solve a problem that in a CLOS-like world require appeal to a second
> mechanism.
>
>     You can also put aside pragmatics and argue that providing namespaces
> automatically with objects is a natural and desirable feature.
> Scoping to the object may not always be the right thing to do (and
> thus may be overused) but it is hard to imagine that it is not
> generally useful.
>
>     DING!  I declare this round goes to object dispatch.


If I understand it correctly, your point is that if you need  the draw
method from gun, picture, blood, and duel modules, that in an
object-dispatch system, you can say:

gun.draw args
duel.draw args
...etc.

instead of
(draw_gun gun args)

But it seems that it should be trivial to have, in a CLOS-style generic
function system, 'draw' bound to a function that would look at the type of
its first argument and dispatch to the appropriate GF. Then you'd have:

(draw gun args)
...
and the only differences would be syntax and the ease with which
autocompletion could be done.

Am I missing something?


-- 
(def (eval e l d c)
  (if  (atom? e)
      ((ahandler (type e)) e l d c)
      (eval (car e) l d
              (fun (x)
                 (evapp x (cdr e) l d c)))))