bug#20423: goops - inheritance of slot options

[David Pirotte <david@altosw.be>]

[-- Attachment #1: Type: text/plain, Size: 3209 bytes --]

Hi Andy,

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

> I don't have any time to devote to this, sorry :/

By 'we rely on you', I was referring to maintaining goops, which you do perfectly
well, thanks!: but you are maintaining an 'hybrid system' with no design, believing
it has, but that's not the case.

Personal notes  and an implementation are not, AFAIC, and far from being, a
'design'.  Besides, with all due respect to the person(s) and his/her technical
abilities, it is obvious to me that he/her/they lack(s) a profound understanding of
the domain, and hence this 'hybrid system' we have now breaks fundamental parts of
the protocol it was [and still is, imo] supposed to follow. It breaks these
fundamental parts of the protocol for no good reason, not a single one, and the
result is an order of magnitude inferior to what it could/should be.

I also strongly believe these issues are actually easy to fix, for you, who
deeply knows the implementation and recently fully reviewed it's source code, so I
don't believe time is the problem here: we disagree on what Goops was originally
meant to be and should be, and right now, I failed to convinced you to revisit your
position, in the light of the above, the official design [clos], what Stklos and
early Goops did implement.

Too bad, because it is the right thing to do, for the good of all guilers, not just
me: this is why I spend my time still trying to convince you that what we have is
not good, and this is not good for Guile, imo.

For users, this issue is easy to 'fix': just copy paste the slot def and locally
change what ever you need to change: 'un plâtre sur une jambe de bois', but at
least it's easy to overcome this current limitation.

Wrt this issue, Stklos and 'early' Goops was following and still should follow this
design:

> [*] A summary of what the clos protocol says:
>
> 	[ this is a copy/paste from a clos tutorial, also pointed by
> 	[ the Stklos reference manual:
>
> 	[	http://www.aiai.ed.ac.uk/~jeff/clos-guide.html#slots
>
> 	When there are superclasses, a subclass can specify a slot that has already
> 	been specified for a superclass. When this happens, the information in slot
> 	options has to be combined. For the slot options listed above, either the
> 	option in the subclass overrides the one in the superclass or there is a
> 	union:
>
> 	   :ACCESSOR  -  union
> 	   :INITARG   -  union
> 	   :INITFORM  -  overrides
>
> 	This is what you should expect. The subclass can change the default initial
> 	value by overriding the :initform, and can add to the initargs and
> accessors.
>
> 	However, the union for :accessor is just a consequence of how generic
> 	functions work. If they can apply to instances of a class C, they can also
> 	apply to instances of subclasses of C. (Accessor functions are generic.)  

Cheers,
And thanks for the hard work anyway!
One day we will agree, I sincerely hope so, for the good of Guile.
David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]