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

Eli Barzilay writes:
 > > If two modules have defmethod forms with the same name, but neither
 > > module requires the other, you end up with two gfs with the same
 > > name.  Then if you require both modules you get a name clash.  Is
 > > there a usual way of dealing with this?  How is this done in CLOS,
 > > or Dylan?  I suppose you could add all the methods of one gf onto
 > > the other, or add all the methods on both to a new gf, but these
 > > seem like kludges.
 > 
 > Well, you do need some place to define the class -- I'd put a
 > defgeneric there and make sure it's provided, so the other defmethods
 > will add to it instead of defining new bindings.

What class do you mean?  These methods are otherwise unrelated except
for their name, so there's no class specializer in common.

 > (In CLOS there is no problem because there is no module system, so you
 > can have (defmethod foo::bar ...) inside a file that defines another
 > package.)

Right, but you still have to know about the other package.  In my
example the two modules are oblivious to each other.  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.

I'm thinking the best answer is to make a new gf that somehow forwards
to (the methods of) the other gfs.  This is pretty much what you have
to do to resolve name clashes in general, either with multiple modules
or multiple inheritance.  The problem is knowing which gf to forward
to.  Perhaps it's enough to call one gf, catching "no such method"
exceptions, which cause the next gf to be called.  Or maybe something
more sophisticated could be done with the MOP that doesn't have the
overhead of an exception handler.  I was just hoping this problem had
already been solved...

--dougo at place.org