Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[Andy Wingo]

Hello again :)

On Sat 07 Feb 2015 01:06, David Pirotte <address@hidden> writes:

>> So, we should be precise with terminology :)  In GOOPS, subclasses do
>> not inherit accessor methods.  (There was a bug in which they would; I
>> fixed that.)  Each subclass gets its own accessor method defined, if and
>> only if it has the corresponding slot, and that method is not inherited.
>
> Here we don't agree, and to me, this is a bug, not a feature :)

Unfortunately if the question is about GOOPS's design, I am certain that
the current stable-2.0 and master behavior follows the design, simply
because it does the same thing as Guile 1.8, before I picked up GOOPS
maintenance and started introducing bugs :)  So let us not argue over
that.  Let us instead treat your concern as request that the behavior
should be different.

> we should follow the clos spec here

Hmm, I agree in general, but you have to understand that the CLOS spec
is not identical to TinyCLOS, the predecessory of stklos.  They are
similar but not the same.  Because of this, diverging from CLOS is not a
bug.

That said I think the CLOS way is usually better, 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.

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.

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

Andy
-- 
http://wingolog.org/