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