[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20423: goops - inheritance of slot options

From: David Pirotte
Subject: bug#20423: goops - inheritance of slot options
Date: Thu, 23 Jun 2016 20:08:57 -0300

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 
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 
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, 
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 
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 
all CLOS implementation do]. Maybe you are referring to some C part of the code 
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 
our GOOPS implementation and start to help maintain it ... if I only had more 
I would have done it already.

Till then we rely on you, And even though I could do it 'right now' we'd still 
unless selfish my own implementation in my little corner, still have to agree 
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 

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

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

        Could you list what you consider a win, for humanity :), in blocking 
        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 

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


Attachment: pgpUXLIRNWKMf.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]