Re: goops - accessors, methods and generics

[David Pirotte <david@altosw.be>]

Hello,

> Right, I had misread part of your initial message by focusing on the
> lack of a superclass.

there is no lack of superclass, your are giving your opinion, which is fine, but i
didn't ask, and actually it is a bad opinion: you don't want to [and don't have to
by clos spec] create a superclass just because of 1 or 2 slot names. besides, this is
a small example, in a large scale system, you may not even know  if other classes
already ... [and should not need to of course, clos/goops is precisly designed to
handle this basic and very common situation].

> However, by not declaring a base module with a superclass in  it you are needless
> complicating interaction with this set of modules.

no, what needlessly complicates things is the unfortunate decision of guilers to
mix goops with the module system:  you do not want any [by far inferior] module
system to interfere with clos/goops. since then you end-up with multiple generics, a
pure non sense. then users/developers, like you, start to re-interpret clos, in a
wrong way, saying that 'there is no common interface' :) of course there is,
'define-class ... dialog...' twice, on purpose, but guile 'broke it', in the name of
its module system, against the clos/goops paradigm.

if at least guile designers and goops implementors would have provided a 'switch'
so that we could ask that any and all goops related stuff being in a single name
space available 'anywhere' at all time [such as guile core functionality is], it
would be great, but reading you, it sounds it is more like a religion problem: not
much we can do when it comes to that. 

> You later suggest to import multiple modules and use merge-generics,
> but that is highly impractical for a user and yourself.

of course, no one should ever merge generics, there should be a single name space
for goops stuff.

but given it is not the case, what is actually impracticle, for anybody, is the
[rather perverse] hidden behavior of guile's module system when I ask to export my
accessors [i should always be able to export an accessor i just defined, and never
forced to know if someone else also did...]: in this case, i obviously expect the
'importer' to receive at the very least what the module that exports has [such as
#<<accessor> dialog (2)>] but hopefully the 'extended generic with setter'. at the
contrary, guile seems to destroy [or recreate?] and export a single class capable
accessor: to my opinion, this is a bug [and the worst language core hidden behavior
i ever faced in my career: i still can not believe it actually: why on earth guile
thinks he knows better then i].

> Consider a user that only imports mg-2, but some how ends up receiving
> a <widget-a>.  They will not be able to operate on that object without
> subsequently importing mg-1 and taking care to merge the generics.

mg-2 should export the generic, as opposed to a single class capable accessor. once
more, clos/goops do not need a module system, if that is the case, it is because you
have a bad oop design and should redesign it better.

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

it should, automatically be created, see clos spec: since i use define-class and
give the accessor the same name, it must obviously consider one generic function and
add the methods appropriatly. export, from any module, should always export the
generic, then import always always work.

> No, the common interface is not *defined* anywhere.  They have similar
> yet distinct interfaces.

then it is a bug caused by the module system interfering with my design, but i
obviously want and have written the source code that asks for a common interface:
'define-class ... dialog ...' twice, on purpose. i do not want to write extra code
and/or modules, i don't want a superclass for this case.

> your real problem with mg-4 lies in the failure to re-export the binding of
> dialog.  

and here comes the real bug i am facing: a guile bug, not a bug of mine: as said
above, i should never have to know whether someone else in his modules, also has
used and exported the accessor name. i should always be able to export what i define
in my module _and_ guile should always export the generic 

> Methods are always for generic functions.  They operate no other way.

sure, i ment one generic per name for the entire system, not per module..

> You are talking about merge-generics, I am talking about a publicly
> defined common interface.  These are not the same. 

clos/goops defines the common interface mechanism. by mixing with the guile module
system, you destroy this mechanism, than the hidden bug(s) we are talking about that
should never appear of course.

> what should a user import when they want accessors for all widgets?  With your
> example, they will have to specifically import every widget-X module *and
> merge-generics* just to get at a common enough interface.

chances are that this user also wants the all module functionality, not just the
'common' accessors. he obviously will import all the modules that he needs and works
with the public interface of each of them. he should not have to merge anything, i
merge [since i am forced to] and export, he receives generics.

> With a base module making the common interface explicit, there is only
> one module to import and you can handle widgets of any class.

that will only work in a small system, not a large scale one where you do not know
'everything'. the small example i gave was actually just an example, but it will
happen in a real and further more large to very large system.

> Within a family of modules, using merge-generics immediately signals the presence
> of design issues.

the design issue comes from the mixing of the module system with goops and since
right now we have no option, the bug in not properly exporting the generic or at
least the 'multiple class capable' accessor(s). this export bug also affects defining
methods on existing 'core' generics [like get/set which comes with the
guile-gnome-platform.

Cheers,
David