Re: goops - accessors, methods and generics

[David Pirotte]

Hi Daniel,

thanks for your answer, but where i understand a strict name space will lead to
merging the generic(s) from/with the ones that comes from the modules you are
importing [as opposed to a general 'goops' name space], i disagree that this 
would be
a 'pre limitation' that provides a proper handling of the problem we are talking
about.

> Note that <generic> is a superclass of <accessor>, so these are
> already generic functions. 

great, so the interface is defined, right?

> Consider these situations followed by introducing any of your example
> class definitions:
> - module A binds ‘define’ to a non-procedure; or
> - modules B and C bind ‘define’ to different procedures.

let's stick to goops, shall we

> In your example the two classes share a common interface, but this
> interface is never defined anywhere.

you just said above that it is, at least for accessors: i am also defending the 
idea
that it should always automatically create a generic function [for methods as 
well]
if none exists.

> So if I have code that wants to  work with any widget, which module should be
> imported to get the canonical interface definition?

the canonical definition comes from the first imported module that [also] 
defines
the generic: this is what occurs in the mg-3.scm example, and that actually 
works
fine, as you know.

however in the mg-4 example, it does not, which i think is an implementation
problem: since i am asking guile to merge... it should import mg-1 and merge 
its own
generics with the imported ones. there is no reason, and certainly not the name
space conservativness, why this is not properly implemented in guile.

> If the interface is the same, you have a candidate for superclass.

yes, that is a possibility, and in some cases i agree that it is the way to go, 
but
it should not be imposed on the user.

Cheers,
David