From: David Pirotte <david@altosw.be>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass
Date: Fri, 6 Feb 2015 22:06:37 -0200 [thread overview]
Message-ID: <20150206220637.310db45e@capac> (raw)
In-Reply-To: <87a90r7wwr.fsf@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 3420 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-02-07 0:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-19 19:46 goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass David Pirotte
2014-12-19 23:42 ` Panicz Maciej Godek
2014-12-20 6:16 ` David Pirotte
2015-01-26 21:35 ` Andy Wingo
2015-01-27 1:00 ` David Pirotte
2015-01-27 8:29 ` Andy Wingo
2015-01-27 19:11 ` David Pirotte
2015-01-27 19:35 ` David Pirotte
2015-01-27 20:44 ` Andy Wingo
2015-01-28 3:05 ` David Pirotte
2015-01-28 3:36 ` David Pirotte
2015-01-28 12:57 ` Andy Wingo
2015-01-28 19:24 ` David Pirotte
2015-01-30 13:50 ` David Pirotte
2015-02-06 13:33 ` Andy Wingo
2015-02-06 17:09 ` David Pirotte
2015-02-06 17:49 ` Andy Wingo
2015-02-07 0:06 ` David Pirotte [this message]
2015-02-07 15:37 ` Andy Wingo
2015-02-07 17:13 ` David Pirotte
2015-02-07 16:08 ` David Pirotte
2015-02-04 16:12 ` David Pirotte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150206220637.310db45e@capac \
--to=david@altosw.be \
--cc=guile-devel@gnu.org \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).