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

[David Pirotte]

Hello Andy,

> May I first please reduce your test case.  Here is an equivalent
> version:

        sure, especially because it is not 'my' test case :)  which got us very
        confused: when you were talking about this one, I was thinking about
        another... which to remove the confusion I finally reported:

                bug #19770: I hope it is 'easy' to solve and hope you can fix it
                soon, to me this one is really important

        but of course I am happy to talk about this one as well, to remove all
        the confusion, if possible :)! and help us getting goops even better!

So, wrt this reduced test, to summarize but see below for details, (1) I agree 
with
you for the first part [the code before defining <ac>], and (2) I have a 
different
answer from my guile version for the second part [which I think is the correct
answer, maybe you wanted to paste some other code [?], don't know.

>   (use-modules (oop goops))
>   (define-class <a> ()
>     (foo #:getter foo #:init-keyword #:foo))
>   (define-class <b> (<a>))
>   (define obj (make <b> #:foo 34))
>   (define-method (foo (self <b>))
>     (pk "ahoy!")
>     (next-method))
>   (pk (foo obj))

>    guile>   (pk (foo obj))
> 
>    ;;; ("ahoy!")
> 
>    Backtrace:
>    In current input:
>      18: 0* [peek ...
>      18: 1*  [foo #<<b> 7fc8898e0e20>]
>       ?: 2   (let* ((next-method (goops:make-next-method self))) (pk "ahoy!") 
> ...)
> 
>    <unnamed port>: In expression (let* (#) (pk "ahoy!") ...):
>    <unnamed port>: No next method when calling #<<generic> foo (2)>
>    with arguments (#<<b> 7fc8898e0e20>)

I totally agree with you and with the above goops 'answer', for all our guile
versions.  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.

> However it wouldn't always return the value of the slot "foo"; for
> example:
> 
>    scheme@(guile-user)> (define-class <c> () (bar #:init-keyword #:bar))
>    scheme@(guile-user)> (define-class <ac> (<a> <c>))
>    scheme@(guile-user)> (define obj2 (make <ac> #:foo 34 #:bar 42))
>    scheme@(guile-user)>   (define-method (foo (self <ac>))
>        (pk "wat!!!")
>        (next-method))
>    scheme@(guile-user)>   (pk (foo obj2))
> 
>    ;;; ("wat!!!")
> 
>    ;;; (42)
>    $2 = 42

Here I am confused again: given the above, defining foo on <ac> and calling
(next-method) is not different then the foo on <b>, there is no next-method and 
I
get the error as well, maybe you wanted to paste some other code? Here is what I
get, given the definitions above (*)

GNU Guile 2.0.11.114-649ec
...
scheme@(guile-user)> ,use (abc)
;;; note: source file ./abc.scm
;;;       newer than compiled...
;;; ...
scheme@(guile-user)> ,m (abc)
scheme@(abc)> (foo obj2)

;;; ("wat!!!")
ERROR: In procedure scm-error:
ERROR: No next method when calling #<<generic> foo (3)>
with arguments (#<<ac> 15c98a0>)

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(abc) [1]> 

>    (defclass <a> ()
>      ((foo :reader foo :initarg :foo)))
>    (defclass <b> (<a>) ())
>    (defvar obj (make-instance '<b> :foo 34))
>    (defmethod foo ((self <b>))
>      (write "ahoy!")
>      (call-next-method))
>    (foo obj)

> Interestingly, in CLISP at least this works in the way you expect:
> ...

Interesting indeed, and a surprise, it's been a very long time I've used CL and 
CLOS.
For info, sbcl also 'works' the same way, but I don't think we should implement 
that
in guile, I second you here:

This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
...
* (defclass <a> ()
* (defclass <a> ()
     ((foo :reader foo :initarg :foo)))

#<STANDARD-CLASS <A>>
* (defclass <b> (<a>) ())

#<STANDARD-CLASS <B>>
* (defvar obj (make-instance '<b> :foo 34))

OBJ
* (defmethod foo ((self <b>))
     (write "ahoy!")
     (call-next-method))

#<STANDARD-METHOD FOO (<B>) {1003B3A773}>
* (foo obj)
"ahoy!"
34
* 

> I am not sure how to interpret this result.

Same here, I should carefully read/study the spec again I guess, but anyway, 
wrt the
the first part of your test case, I agree with you.

>  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.

>  Could it be that in CLOS, all instances  of a type are considered to have all
> slots of all supertypes?  That is not the GOOPS design, but perhaps that 
> should
> change.

I am confused with what you mean exactly with the above sentence, which to me is
'correct' and with which you seem to disagree?  But for me, if that is what we 
are
talking about here, goops class-slots procedure does the right job.

Cheers,
And thanks!
David


(*)     here an abc module from the defs of your email:


(define-module (abc)
  #:use-module (oop goops))


(define-class <a> ()
  (foo #:getter foo #:init-keyword #:foo))

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

(define-method (foo (self <b>))
  (pk "ahoy!")
  (next-method))

(define-class <c> ()
  (bar #:init-keyword #:bar))

(define-class <ac> (<a> <c>))

(define-method (foo (self <ac>))
  (pk "wat!!!")
  (next-method))

(define obj (make <b> #:foo 34))
(define obj2 (make <ac> #:foo 34 #:bar 42))

pgpjK0S5d479X.pgp
Description: OpenPGP digital signature