Hi It seems you are expecting some CLOS behaviour in a language that can not support it. The accessors are generic functions, but each of your modules creates a unique generic function, there is no implicit namespace sharing in Scheme. Define a base module with an appropriate superclass or interface definition (generics); Scheme requires it.
On 22 February 2013 06:51, David Pirotte <da...@altosw.be> wrote: > Hello all, > > given the following 4 modules, I am facing what I consider an > inconsistent goops behavior and have one problem which leads to my > recurrent request of goops default behavior should be to > [a] always > create a generic function for accessors and methods that do not [yet] > have one, *visible in the entire guile space [all modules]* Note that <generic> is a superclass of <accessor>, so these are already generic functions. There is no global binding escalation in Scheme. 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. Your suggestion is appropriate in a language like Common Lisp with dynamic scoping, and separate namespaces for function and non-function bindings. Not so appropriate for Scheme. In your example the two classes share a common interface, but this interface is never defined anywhere. So if I have code that wants to work with any widget, which module should be imported to get the canonical interface definition? Indeed, it will either have to be created using a common superclass or manually defined generics (as you later observe). These widget implementations will then have to import the base module to explicitly share in the interface. > and [b] the > default behavior should be '(merge-generics replace warn-override-core > warn last) [but that at least that one I can set using :duplicate, I know] The default behaviour is conservative with regards to namespace separation. If you desire this behaviour it seems best to explicitly ask for it. With CLOS a different default can be expected to apply because bindings in the underlying language already work in a similar way. > what is more of a problem with the existing goops default, for me, is > expressed in the mg-4.scm 'case': i can not make it work unless I > manually create another module, manually making generics and make sure > it is loaded before ... In a language like Scheme this can not be avoided. Namespaces must be managed quite explicitly. In your example, mg-1 and mg-2 are not sharing any bindings. It is not appropriate to assume that ‘dialog’ in either is related to the other. If they implement a common interface, as seems obvious in the example, then they need to import the generic bindings for that from a common base module. Such a module should either define a superclass or you can manually define the generics. > or rename the accessors, which both solutions > are really against my expectation and [long] CLOS practice: why should > I have to manually do things which are inherent to oop [same name for > slots pertaining to different classes is so common that i can not see > any large application not having to do so, for semantic reasons]. GOOPS can not do everything the same as CLOS due to fundamental differences between the underlying languages. If the interface is the same, you have a candidate for superclass. Either way, any code that hopes to use the (generic) interface needs to import the bindings from somewhere, and that will be a module containing either a superclass or a set of manually defined generics. Regards
