Re: Trouble understanding define (!)

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Michael Livshin <mlivshin@bigfoot.com> writes:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> 
> > Extensions *don't* propagate back with my suggested change.  The call
> > to mumble will result in A:grumble reporting "no applicable method".
> > 
> > The question now is if this is what we want.
> > 
> > Part of the answer is: certainly *not* in the case of the MOP.
> 
> hmm.  I rather thought we do, generally.  and how is the MOP special?
> (MOP's raison d'etre is that it is something that doesn't appear
> any different from any other object library, isn't it?).

Well, earlier there were voices raised for supporting a kind of
encapsulation where new methods aren't added to GFs exported from
modules.  This would work in many cases, but would not work for the
MOP.

Generally, I think the right way is to modify the exported GFs.

> P.S.  I remember there was a discussion on this very list a year or so
> ago, in which Cristian Lynbech (well, I believe that was him) dug out
> some paper by Kiczales et al which basically said that all you need in
> order to not break CLOS libraries is to abide by one simple rule : "no
> external overrides".  perhaps it's relevant, perhaps not...

It's very relevant.  I've read it twice, but, obviously, I was
temporarily disconnected from that piece if knowledge (as Terry
Pratchet's witches say: "people have walls in their heads" :).

The Scheme solution corresponding to Kiczales' paper would probably be
to have a special module containing all generic functions.  This is
because the paper is not considering use of the package system.

But, I gather that if Common LISP people are using their symbol-level
package system, they get into exactly the same problems as we when we
combine the current GOOPS with our module system.  Could some Common
LISP/CLOS person verify this?

The problem, as I see it, is that it is uncomfortable for the user to
manage the question of which GFs of the same name really should be
represented as one GF.

We might have one graphics library which provides a set of methods for
the GF `draw'.  Then we might use this in a Poker game where we have a
GF `draw' which draws cards in different ways depending on what kind
of pack of cards we have.

It is clear that these two GFs represent different concepts, and one
way of handling the situation in the module system is to import with
renaming: g:draw, card:draw.

For most other situations, the current mechanism works well if you
follow the rules in Kiczales paper.

But it's still very irritating to have to explicitly rename the
numerous slot accessors, and I don't see it as a problem if g:draw and
card:draw above would be merged into a single GF.  We would get such
an effect by having a single GF module, but this solution seems to
have scalability problems.  There certainly are situation where one
would like to keep GFs local to one module.

To summarize: Maybe we actually want to merge GFs which get
"connected" through the module system, but not in other cases.

This is certainly achievable, e.g. by using the kind of indirection
suggested by the <extended-generic> solution mentioned earlier.

Suggested new solution:

  GFs in different modules are distinct objects, but GFs whose names
  "meet" through the module system share methods."

More precisely:

1. Every module has it's own GF object.

2. Each GF refers to a "pool" of methods.

3. Many GFs can refer to the same pool of methods.

4. If a method is added to one GF, it is visible for all other GFs
   using the same pool.

5. Each GF created by `define-generic' initially has a private pool.

6. Exporting GF1 bound to NAME in module A to module B means binding
   GF0 to name NAME in module B and letting GF0 and GF1 refer to the
   same pool.

7. Exporting GF1, GF2, ..., GFn bound to NAME in modules A1, A2, ...
   to module B means binding GF0 to name NAME in module B and letting
   GF0, GF1, ..., GFn refer to the same pool.

Essentially, it's a percolation process where the imported bindings
are holes.  :)


This suggestion is admittedly a bit weird, but it will both be
efficient (if the right datastructure is selected) and very practical.