Re: Generics vs. Message passing: object namespaces

On 2/23/07, Michael Walter <[email protected]> wrote:
>
> On 2/23/07, [email protected] <[email protected]> wrote:
> > > 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?
> >
> >
> >     No, I think that is correct, but that is not how CLOS-style generic
> > OOP works, the original subject of criticism. [...]
>
> In what way is using dynamic dispatch not how CLOS-style generic OOP
> works? I mean, this seems to be pretty much what defgeneric/defmethod
> are for.
>
> Regards,
> Michael
>

The difference is that if you define 3 different GFs (not different methods
on a single gf, but 3 different functions) in different source files, each
with the same name, CLOS does not automatically smash them together into a
sngle, more generic function.  That would be necessary to make

(draw gun )
(draw picture)

work the same way as
gun.draw
picture.draw


-- 
(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)))))