[plt-scheme] Swindle question: multiple gf defs with the same name

From: Eli Barzilay (eli at barzilay.org)
Date: Sat Aug 7 19:01:24 EDT 2004

On Aug  7, Doug Orleans wrote:
> Right, but the methods might operate on different (unrelated)
> classes.  Think of the (draw window) vs. (draw gun) example.
> There's a window module and a gun module, and they each (implicitly)
> define a draw generic; there's no common class module to move them
> into.

OK.


> It's not the providing that would be tedious, but having to define
> the generics in one place and the methods in another.  For example,
> defclass generates multiple accessor methods (and generics), so
> you'd have to put all the accessor generics into the common module
> just in case another class wants to use the same accessor names.

Yeah, I see what the problem is now.

I don't see any `clean' solution.  The problem is that every module
has its own namespace, even if you modify the behavior of defmethod to
just do the add-method thing, you will run into the same problem of
where should you define the generic.  So if you don't want to do the
common gf-module thing, you have to combine things later using some
hack.  Either run-time delegation from one gf to another, or anything
else, the point is still the same.


> Sure, I don't mind imposing an ordering, just like you have to
> choose an order for superclasses with multiple inheritance.

Actually, you can test things so the combine-generics will throw an
error if there are two methods with the same specializers...  Seems
like this would be fine for your purpose.


> The problem is that methods that are later added to A:foo or B:foo
> wouldn't be added to C:foo.  But I don't know your MOP well enough,
> perhaps there's some mechanism for intercepting add-method on the
> original gfs.

Yes, add-method is itself a generic function, so you can redefine its
behavior on the original gfs.  But I don't think that this is really
needed -- once you combine A:foo and B:foo into a C:foo, you really
don't want the original ones, since C:foo should override them.


> (In case you hadn't guessed, I'm not actually doing this in Swindle
> but my own language with multimethod-ish constructs.)

No, I didn't guess...  (A completely new implementation or a scheme
implementation?)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!


Posted on the users mailing list.