This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Trouble understanding define (!)


Neil Jerram <neil@ossau.uklinux.net> writes:

>    * importing generics from another module (should one binding of a
>      generic shadow another with the same name, or should the module
>      system create a new generic function, containing a union of the
>      methods; I actually begin to favor the latter alternative)
> 
> Unfortunately I think we have to do the latter.  Otherwise we have a
> situation where two unrelated applications (but in the same Guile
> process) can interfere with each other by adding methods to the same
> generic function imported from another module.
> 
> The problem is, what depth of copying do we need from the old generic
> function to the new one?  Is it enough to copy the methods by
> reference, or do they need to be duplicated as well?

It should be OK to copy methods by reference.

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]