[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
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