Re: Trouble understanding define (!)

[Michael Livshin <mlivshin at bigfoot dot com>]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Actually, it seems to me that we can't just make a new generic
> function for the module using it.  This problem requires some more
> thinking.  E.g., what if we during interactive development work fix a
> bug in the original GF.  We would then very much like the method to
> "propagate" to all GFs derived from it...
> 
> Maybe the set of methods could be regarded as part of the type of the
> generic function and maybe we could look upon the new GF as a subclass
> of the original.  If we do this, we get the "propagation" for free
> since this is handled by the class update protocol.

sounds like much hair.

note that this problem stems from a CLOS syntactic "convenience
feature": CLOS (and GOOPS) lets you use `define-method' without
preceding it with the relevant `define-generic'.  so a user-burdening
solution would be to revoke this "convenience feature", thus ensuring
that the generic is defined *once*, and that if it is not then surely
the user means two different generics which happen to share the same
name.

without revoking the "convenience feature" we have basically two
choices :

1) blithely go ahead and ensure that the two (or more) accidental
   generics are *merged* ("destructively" and retroactively) into one
   (quite possible with the MOP, I guess).

2) bomb out with a name conflict.

3) [so I lied about the two choices] do 1) for slot-accessor generics
   and 2) for the rest (assuming it's possible to cleanly separate the 
   cases, i.e. the user's intent).

looks like I'm for 3) if the relevant assumption is true.  though the
really clean solution would be to ban `define-method' without
preceding `define-generic', IMHO.

--mike

-- 
I'm sorry, the teleportation booth you have reached is not in service at
this time. Please hand-reassemble your molecules or call an operator to
help you....