bug#20423: goops - inheritance of slot options

[David Pirotte]

Hi Andy,

> For what it's worth this is a part of GOOPS's design AFAIU: all slot
> definitions are unique.  Two slots named S declared on classes A and B
> are distinct, even if A is a superclass of B.

Well, as I explained in the original report, the only specification we have is 
CLOS:
Stklos, upon which Guile GOOPS is based, clearly state in its manual, among the
first paragraphs, that it implements the CLOS protocol [a subset]: there is no
'redesign' anywhere in Stlkos [it just lacks :before and :after methods AFAICT].

AFAICT, there is no Guile 'official' document stating clearly, neither in the
manual, that GOOPS authors decided to redesign this part of the protocol and 
why...
is there?

It seems to me, in this rather unfortunate case, that you take for a 'design' 
or a
'redesign', what was actually a great implementation to start with, no doubt, 
but
which has these bugs, implementation bugs, not design decisions.

> I don't know if we can change this.  I guess maybe.  There would have to
> be a design though.  I guess fleshing out the `compute-slots' protocol
> from http://www.alu.org/mop/concepts.html#class-finalization-protocol
> would be the thing.

Not sure what you mean by 'we can't change this', but I hope/think it can be 
fixed,
technically I don't see what could prevent this to be done since Stklos does the
right thing... [I'm pretty sure gauche does the right thing too, and in any 
case,
all CLOS implementation do]. Maybe you are referring to some C part of the code 
I'm
not aware of that would effectively prevent a fix, don't know...

> I believe that technically you can already provide your own
> `compute-slots' implementation, but you are probably missing some
> definitions that would help you do so in a compatible manner.  Check it
> out for yourself and give it a go, no need to wait on Guile people :)

        Right: if you want it right do it yourself ... :) 

It actually is my intention, it has been for years, to study, dig into and work 
on
our GOOPS implementation and start to help maintain it ... if I only had more 
time,
I would have done it already.

Till then we rely on you, And even though I could do it 'right now' we'd still 
have,
unless selfish my own implementation in my little corner, still have to agree 
upon
the design reference document(s) GOOPS has been/should be based  upon:

        and I want GOOPS to follow the CLOS protocol, for its entire subset, 
not just
        for me, but any Guilers, and especially the one that will learn oop 
using
        GOOPS;

        the above, especially for getters, setters, accessors inheritance _and_ 
this
        bug, slot redefinition.

So, rather then being a technical problem, we strongly disagree, unfortunately, 
on
what GOOPS protocol should implement, don't you think it would be better to 
follow
the CLOS protocol?

        Could you list what you consider a win, for humanity :), in blocking 
slot
        option redefinition and inheritance to be blocked?

        Could we talk to the original GOOPS author, and if so, would you be
        convinced, if he confirms of course, that all these are bugs and not 
design
        decisions?

All this said, I wonder, before I start :), if the still C part of the code 
would
prevent me to patch GOOPS so it fully respect the CLOS protocol?

Thanks,
David

pgpUXLIRNWKMf.pgp
Description: OpenPGP digital signature