[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: goops - guile-clutter unexpected bug while using #:virtual slot allo

From: David Pirotte
Subject: Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass
Date: Fri, 6 Feb 2015 15:09:33 -0200

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 
you for the first part [the code before defining <ac>], and (2) I have a 
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 
get the error as well, maybe you wanted to paste some other code? Here is what I
get, given the definitions above (*)

GNU Guile
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 
For info, sbcl also 'works' the same way, but I don't think we should implement 
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 <>.
* (defclass <a> ()
* (defclass <a> ()
     ((foo :reader foo :initarg :foo)))

* (defclass <b> (<a>) ())

* (defvar obj (make-instance '<b> :foo 34))

* (defmethod foo ((self <b>))
     (write "ahoy!")

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

> 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 
talking about here, goops class-slots procedure does the right job.

And thanks!

(*)     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!")

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

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

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

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

Attachment: pgpjK0S5d479X.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]