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

Eli Barzilay writes:
 > On Aug  7, Doug Orleans wrote:
 > > What class do you mean?  These methods are otherwise unrelated
 > > except for their name, so there's no class specializer in common.
 > 
 > Supposedly you're working on some data and there is some place where
 > you define that data (classes, structs or whatever).

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.

 > > They could both be made to require a common module that defined the
 > > gfs, but it would be tedious to make every single gf definition
 > > explicit in this common module, especially if they're usually
 > > macro-generated by some form that expands into multiple defmethods.
 > 
 > (defgeneric* foo (...))?

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.

 > There is a `no-next-method' generic that you can override, but I don't
 > know if what you're talking about makes sense.  If you simply make a
 > generic give up and send its arguments to another, then you won't see
 > some methods.  For example:
 > 
 >   module A: (defmethod (foo (x <integer>)) ...)
 >   module B: (defmethod (foo (x <integer>)) ...)
 >   module C: (require (prefix A: A) (prefix B: B))
 >             (define foo (combine-gfs A:foo B:foo))
 > 
 > will always ignore one of the <integer> methods.

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

 > But if you think
 > that this makes sense, you can write a `combine-gfs' that works
 > slightly better -- instead of making A:foo go to B:foo when giving up,
 > you could just make a new gf, then add all the generic-methods of
 > A:foo and B:foo to it.  (Of course you still need to choose which ones
 > get added last...)

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

--dougo at place.org