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
pgpknF2Euq9Sa.pgp
Description: OpenPGP digital signature
