> Hello again :)

Yes, hello,
Saturday greetings!

> ... So let us not argue over that.  Let us instead treat your concern as request
> that the behavior should be different.

Perfect, let's talk about ... should we, how, how much :) ...
 
> > we should follow the clos spec here

> That said I think the CLOS way is usually better

Agreed, definitely:  I'm well aware that it is a very complex task to implement it
correctly [and fully, but I don't need the full protocol either, 1 day maybe...], and
very 'frustrating' too, since it is almost impossible to make it run 'fast', by
definition, as you know. of course ... But I really need the subset we have in goops
to implement the corresponding clos subset protocol, especially what we are talking
about.

> but we are limited by  two things: compatibility with past behavior (not a
> terrible concern in this instance, given the lack of outcry when I broke things),
> and secondly by hack-power.  In particular I do not have any additional free
> time to spend on GOOPS features in the near future.

Would you have some available pay time? If so, could you send me a private quote, I
need this change asap, and if the quote is reasonable, you could start immediately.
If you [guilers] think it should also be in goops, fine, I am happy to 'fund
that part of the protocol for all' :)  If not, could you include in the quote a
bit of time to implement a git branch with goops only, name it gclos or what ever
is [more] appropriate , if that is possible [?], so that I can always and in a very
easy way, track stable-2 [master in the near future] but apply 'my' goops [I
mjean (re)configure/make/make install 'my' goops...


> This feature you are asking for requires:
> 
>   * more logic in method-applicable? for accessor methods that would
>     1. check the list of effective slot definitions in the target object
>     2. for each slot, get the direct slot definition
>        - currently there is no long from effective to direct, we'd have
>          to add that
>     3. if the target object has a slot with the same direct slot
>        definition as the one associated with the accessor method, then
>        the method applies, otherwise not
> 
>   * compile-time specialization for methods, as in
>     583a23bf104c84d9617222856e188f3f3af4934d which was later reverted
> 
> Open questions would be, do we expose method-applicable? as a generic,
> there's some gnarly circularity because these methods are part of the
> method dispatch protocol, do we expose more of the slot protocol to
> users (it's currently somewhat opaque and unfinished), how to document
> all of this, we need a bunch of tests too, how do you relate effective
> slots to direct slots in the CLOS case where you can make composite
> slots, etc.

I will answer this part a bit latter, I need to think about it :)

> It's a bit of work and I need to do other things :)

Sure,
I have too, 
Let's see if you are interested and has pay time available...

Cheers,
David