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

[David Pirotte]

Andy,

> Are you certain?  What git revision are you using?  I don't think the
> test should "work" with the current stable-2.0 or master, or 1.8 for
> that matter.

>     $ /opt/guile-1.8/bin/guile
>     guile> (use-modules (oop goops))
>     guile> (define-class <a> ()
>     ...    (width #:accessor width #:init-keyword #:width #:init-value 0))
>     guile> (define-class <b> (<a>))
>     guile> (define b (make <b>))
>     guile> (width b)
>     0
>     guile> (set! (width b) 10)
>     guile> (width b)
>     10
>     guile> (define-method ((setter width) (self <b>) width) (next-method))
>     guile> (set! (width b) 10)
> 
>     Backtrace:
>     In current input:
>       10: 0* [setter:width #<<b> 7f795ed527e0> 10]
>        ?: 1  (let* ((next-method (goops:make-next-method self width)))
> (next-method))
> 
>     <unnamed port>: In expression (let* (#) (next-method)):
>     <unnamed port>: No next method when calling #<<generic> setter:width (2)>
>     with arguments (#<<b> 7f795ed527e0> 10)
>     ABORT: (goops-error)

When talking about goops, we should not refer to 1.8 (*), 1.6 or any guile 
version
for that matter, but to the clos language spec subset goops implements [appart 
from
the adaptation for it to be module protected, but that is not the point here].

This said and with that in mind, the implementation you say was in guile-1.8 and
that it appears you have reimplemented 'right now' breaks the specification and
afaiac makes goops totally unusable for any serious work: this is a catastrophy,
please reconsider!

        -] anything defined by a user using define-method _must_ pass thought 
the
        exact same computation machinery _and_ all become applicable methods;

        -] within the core of a define-method, one must always be able to call
        (next-method) [of course if the user do so inappropriately it raises an
        error, I'm not talking about that];

        -] they is no exception for setters, which are _just_ methods, with, in
        addition and as we know, a bit of 'magic' so that they can be used with 
set!
        
                -> otherwise, there would be 2 define-method semantics
                -> that can't be, and if it was the case the clos 'comity' would
                have defined another method for setters such as
                define-setter-method, and restrict that method from being able 
to
                call (call-next-method);

        -] within the core of methods, including the ones called with 
(next-method)
        calls to slot-ref slot-set! must _always_ call the instance(s) slot-ref-
        slot-set! as defined by the system [if none were provided], or the 
user's
        code they were provided [such as when #:allocation is #:virtual]

We should not need any really, but here is a description [no code, no need to at
this point] of a [still very simple] 'visual' example, so everyone can follow:

        let's define a gravity sensitive class <apple> and a !gravity setter, 
which
        sets the position of the instance on a scene and takes care of its 
layout
        [as in 'horizontal or 'vertical] depending on the gravity poles the 
instance
        respond to: at some point this setter method calls sot-set! to set the
        instance position slot value, such as 'north-west;

        then we define a <toolbar> class, which inherit from <apple>, with
        an item slot filled with <button> instances, each button having an 
optional 
        <tooltip> instance [a text, "My beautiful tooltip..."];

        each tooltip text must 'glue' to there button _and_ always be entirely 
on the
        scene [visible to the user, if the scene is itself visible of course, 
but
        that's not the question here]:

        -> that means there is extra work to be done on toolbar instances, but 
we
        want to run the <apple> !gravity setter code first

        (define-method ((setter !gravity) (self <clus-toolbar>) gravity)
          (next-method)
          (for-each (lambda (toolbar-item)
                      (ensure-tooltips-on-stage toolbar-item))
            (!items self)))

Cheers,
David

(*) Besides, let me tell you that I never intensively used goops before 
guile-2, but
just played a little with it, precisely because I could not trust it, as I had 
my
heisen bugs using guile 1.6 because in these past times I could not even trust 
the
module system

pgphcz0aWGfXy.pgp
Description: OpenPGP digital signature