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

[Andy Wingo]

On Tue 27 Jan 2015 02:00, David Pirotte <address@hidden> writes:

>>  Can you make a test case without guile-gnome?
>
> No, it is a guile-gnome problem/bug, so here below, a very short test case (*)

OK, then please file it in the guile-gnome bugzilla.  Thanks.  We
probably don't need to talk about it on guile-devel.

> (*) I agree with you that this is less important then goops bugs of course, 
> and I
> would be particularly interested to get the setters inheritance bug solved 
> before
> anything else [if not done already as I write this answer :)].  Beside I 
> found a way
> to circumvent this problem, not perfect but ok, so no rush for this one.

The setters inheritance bug is fixed to be like 1.8.  I'll write another
mail, but briefly the idea is this: an accessor on a slot (or a getter,
or a setter), declared via #:accessor or #:getter or #:setter, is used
to access the value of the slot in which it is declared.  However not
all subclasses of a class have all slots of their superclasses;
consider:

  (define-class <super> ()
    (a #:accessor access-a))

  (define-class <sub> ()
    (a))

<sub> declares a *new* slot that happens to also have the same name,
`a'.  But all slots in any particular class have to have different
names, so there's a procedure that builds the composite list of slots
for any given class in the hierarchy, taking as input the class
precedence list and the direct slots of all classes in that list.  It
prefers slots declared in more specific classes, so <sub> will have its
own slot `a' *and not* the slot from <super>.

So for that reason, the accessor `access-a' *does not apply* to
instances of <sub>.  Applicability of accessor methods is based on
whether the given class has the given slot, not based simply on the
CPL.

Now, I broke this in 2009, so it has been broken for all of Guile 2.0.
I fixed it yesterday though, as it's in keeping with 1.8, and it was
just wrong.

OK.  So what about your case?  Well it's this: if you do this:

  (define-method (access-a (obj <sub>)) (next-method))

There is no next method, because the access-a accessor method from
<super> doesn't apply to <sub>, so you will get a no-applicable-method
error.

If you want to have generics that "inherit" accessors you'll have to
come up with some other pattern.

Andy
-- 
http://wingolog.org/