[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile-2.2 - goops setters should be inherited, no matter what :)
From: |
Andy Wingo |
Subject: |
Re: Guile-2.2 - goops setters should be inherited, no matter what :) |
Date: |
Tue, 14 Mar 2017 13:23:31 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hi,
On Sun 26 Feb 2017 23:57, David Pirotte <address@hidden> writes:
> 1- setters, as in (define-method ((setter ...) (self <...>) ...) ...)
> should (also :)) be inherited,
As you mention this is https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19770.
I think we have an understanding about why things are the way they are
in GOOPS, and you are arguing that they should be different -- different
from 1.8 and 2.0. That's OK and making a different system is possible
if we have good reasons. It's also possible to extend the current
system to implement new behaviors.
In this case though I don't know how to make a consistent system with
the semantics you are looking for and without losing some of the speed
of the current system. I guess you would want for the class defining
the slot to define a method that just does (slot-set! obj 'slot x), and
not have concrete subclasses define their own accessor methods, thereby
avoiding accessors entirely. In that case I would think you could
define slots with a different kind of class, or override the slot
definition protocol or something, or use a different define-class
wrapper or something.
In short I think I just don't agree with this change as part of standard
GOOPS, so I propose the second solution: to make sure you can implement
the behavior you want as a user. What about using a wrapper
define-class macro that removes "#:accessor foo" from its slot
definitions and translates those to issue definitions like this:
(define-method (foo (x <obj>)) (slot-ref x 'foo))
(define-method ((setter foo) (x <obj>) val) (slot-set! x 'foo val))
Andy
- Re: Guile-2.2 - goops setters should be inherited, no matter what :),
Andy Wingo <=