Re: Guile-2.2 - goops setters should be inherited, no matter what :)

[David Pirotte]

Hi Christopher,

        You are confusing/mixing two different issues, precisely the two issues 
I'm
        talking about in my two separate emails, but you mixed them here :)

        I'd rather keep them well separated, because fixing the first should be 
very
        easy, it is a matter of agreeing (and a bit of work of course, adapting 
the
        test suite... I'm not saying it is zero work :)), where as fixing the
        second, slot redefinition at subclass to follow the clos protocol, 
represent
        quite a lot of work, so it is not just a matter of agreeing...

> >     - both the accessor and the setter should be inherited  
> 
> I've run into unexpected issues where I redefined a slot and didn't
> remember to set the same getter/setter/accessor.

As things are, both in 2.0 and 2.2, if you redefine a slot, it is a new slot, 
nothing
is inherited (wrt to the slot I mean, methods are of course):

        but this refers to my other email, let's keep the issues separated

> But why just setters and accessors?  Why not also getters?

As I said above, When you do _not_ redefine the slot at subclass level, 
everything
is inherited, except setters, hence my original bug report and this fresh email
which contains a much better explanation/situation description for Andy to 
'play'
with ...

> It may also be worth asking, what other slot fields get inherited?
> Would #:init-keyword?  #:init-value?  #:init-thunk?  Inheriting
> #:init-value and #:init-thunk both could be confusing (what does CLOS
> do?).  What about #:allocation?

This refers to the other issue, and what clos does is in the summary of that 
email,
as well as in the original bug report, which has links to further read ... of 
course
the full protocol is in the spec

Cheers,
David

pgpxKj5csFHGX.pgp
Description: OpenPGP digital signature