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

[David Pirotte]

Hi again!
:)

> With the stable-2.0 or master branches, the current behavior is:
> 
>     scheme@(guile-user)> (use-modules (oop goops))
>     scheme@(guile-user)> (define-class <a> ()
>     ...   (foo #:getter foo #:init-keyword #:foo))
>     scheme@(guile-user)> (define-class <b> (<a>))
>     scheme@(guile-user)> (define obj (make <b> #:foo 34))
>     scheme@(guile-user)> (define-method (foo (self <b>))
>     ...   (pk "ahoy!")
>     ...   (next-method))
>     scheme@(guile-user)> (pk (foo obj))
> 
>     ;;; ("ahoy!")
>     ERROR: In procedure scm-error:
>     ERROR: No next method when calling #<<generic> foo (2)>
>     with arguments (#<<b> 2c207e0>)
> 
>     Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>     scheme@(guile-user) [1]> 

Yes, expected, but to me, it is because of what I just said here below.

> > In this case indeed, the only method that exists and is applicable is
> > the getter foo that <a> defines and<b> inherits: there is no
> > next-method and calling (next-method) would be a user bug, in my
> > opinion too.
> 
> 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 :), given that in 
my
opinion (1) we should follow the clos spec here, and (2) you did the right 
thing in
2009, even by accident, it was a very good accident :).  Besides, the following
would work [i don't think it is a/the solution, the user should be 'forced' to 
do
that, I mention it here to show what I consider a 'contradiction']:

wdyt?

;;; module a.scm starts here
(define-module (a)
  #:use-module (oop goops)
  #:export (<a>
            !width
            set-width))

(define-class <a> ()
  (width #:accessor !width #:init-keyword #:width #:init-value 0))

(define-method ((setter !width) (self <a>) width)
  (set-width self width))

(define-method (set-width (self <a>) width)
  ;; here comes complex code, computing earth orbit, captain's age...
  (pk "this is <a> !width setter method, hello!")
  (slot-set! self 'width width)
  width)
;;; module ends here


;;; module b.scm starts here
(define-module (b)
  #:use-module (oop goops)
  #:use-module (a)
  #:export (<b>)

  #:re-export (!width
               set-width))


(define-class <b> (<a>))
;;; module ends here

GNU Guile 2.0.11.114-649ec
scheme@(guile-user)> ,use (oop goops)
scheme@(guile-user)> ,use (b)
;;; note: source file ./b.scm
;;;       newer than
;;; ... ...
;;; note: source file ./a.scm
;;;       newer than
scheme@(guile-user)> (make <b>)
$3 = #<<b> 1bc1940>
scheme@(guile-user)> (set-width $3 20)

;;; ("this is <a> !width setter method, hello!")
$4 = 20
scheme@(guile-user)> 


> >>  The slot definition protocol in CLOS is different; for example,
> >> compute-effective-slot-definition in CLOS logically *combines* slot
> >> definitions with the same name.
> >
> > Is it not what goops does as well? I thought so.
> 
> Nope :)  That bit of the protocol was never implemented.  Instead the
> semantics are that the slot from the first entry in the CPL is used.

Ok, I can live with that for now :)

Cheers,
David

pgpxQYdlyBShT.pgp
Description: OpenPGP digital signature