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
