Re: Trouble understanding define (!)

[Neil Jerram <neil at ossau dot uklinux dot net>]

   > A problem arises, however, when more than one application runs in the
   > same Guile process, and different applications mix behaviours 2 and 3
   > for the same generic function.  What can then happen is that
   > application A's behaviour is unexpectedly modified because application
   > B added a method to a generic using behaviour 2.
   > 
   > To my mind, this is the main problem, but I have a strong feeling that
   > I'm out of sync with everyone else on this!  What other key problems
   > are there?

   This problem is actually solved by adhering to the principles in
   Kiczales' paper, and doesn't need any new functionality in the module
   system.  (We might be able to add support for automatic assertion that
   some of his rules are followed.)

Agreed.  (This is a very useful paper - and a pity that I didn't read
it before attempting to document the MOP!)  It would be good to
support automatic assertions here.

According to Jost, Bertrand Meyer recommends a restriction that is, I
think, a generalization of Kiczales' rules, viz. that an application
should never be able to modify a module's internal state in such a way
that the behaviour observable by another application is different.

If we followed this more general restriction, there would be no need
for my ideas about modules being shareable or non-shareable.  But
maybe this would be just too restrictive.

Regards,

        Neil