Re: #:getter procedure returns unexpected value in GOOPS

[David Pirotte <david@altosw.be>]

[-- Attachment #1: Type: text/plain, Size: 3826 bytes --]

Hello Andy,

Le Mon, 09 Mar 2015 22:58:20 +0100,
Andy Wingo <wingo@pobox.com> a écrit :

> Hi!
> 
> On Sat 26 Apr 2014 01:24, "Diogo F. S. Ramos" <dfsr@riseup.net> writes:
> 
> > When using GOOPS, if a class has a second slot, the #:getter procedure
> > of the first slot returns the value of the second slot when applied to
> > an instance of a subclass.
> >
> > (use-modules (oop goops))
> >
> > (define-class <foo> ()
> >   (a #:init-form 'foo #:getter foo-a)
> >   (b #:init-form 42))
> >
> > (define-class <bar> (<foo>)
> >   (a #:init-form 'bar))
> >
> >   (foo-a (make <foo>)) => foo
> >   (foo-a (make <bar>)) => 42
> >
> > I expected:
> >
> >   (foo-a (make <bar>)) => bar
> 
> I realize this is really late :)  But since this thread isn't linked to
> a bug, note that this is now fixed in stable-2.0 and master, to match
> the behavior in Guile 1.8 and previous, which is actually that:
> 
>   (foo-a (make <bar>)) => error!
> 
> because <bar> doesn't just define a different init-value for the slot,
> it defines a different slot entirely.

I'm late too :)

I am afraid this was an unfortunate and quite terrible [design? I doubt] bug in
Guile-1.8 then. Indeed, even Stklos does correctly implement subclass slot
redefinition as specified by the clos protocol [*]

;;; subclass-slot-redefinition.scm starts here
(define-class <person> ()
  ((name :accessor name :init-keyword :name :init-form "")
   (age :accessor age :init-keyword :age :init-form -1)))

(define-class <teacher> (<person>)
  ((subject :accessor subject :init-keyword :subject :init-form "")))

(define-class <maths-teacher> (<teacher>)
  ((subject :init-form "Mathematics")))
;;; ends here

david@capac:~/alto/projects/stklos 8 $ stklos
*   STklos version 1.10
 *  Copyright (C) 1999-2011 Erick Gallesio - Universite de Nice <eg@unice.fr>
* * [Linux-3.16.0-4-amd64-x86_64/pthread/readline/utf8]
stklos> (load "subclass-slot-redefinition.scm")
stklos> (define p2 (make <maths-teacher> :name 'john :age 34))
;; p2
stklos> (describe p2)
#[<maths-teacher> b34420] is an an instance of class <maths-teacher>.
Slots are: 
     age = 34
     name = john
     subject = "Mathematics"
stklos> 

[*]

In summary, the clos protocol says:

	[ this is a copy/paste from a clos tutorial, also pointed by
	[ the Stklos reference manual:

	[	http://www.aiai.ed.ac.uk/~jeff/clos-guide.html#slots

	When there are superclasses, a subclass can specify a slot that has already
	been specified for a superclass. When this happens, the information in slot
	options has to be combined. For the slot options listed above, either the
	option in the subclass overrides the one in the superclass or there is a
	union:

	   :ACCESSOR  -  union
	   :INITARG   -  union
	   :INITFORM  -  overrides

	This is what you should expect. The subclass can change the default initial
	value by overriding the :initform, and can add to the initargs and accessors.

	However, the union for :accessor is just a consequence of how generic
	functions work. If they can apply to instances of a class C, they can also
	apply to instances of subclasses of C. (Accessor functions are generic.)

Note that the last sentence, which applies to getters and setters of course, is of
prime importance wrt our previous conversation and my reported bug about setters,
which must be inherited:

	wrt setters not being inherited, the current situation not only creates
	technical problems [it forces users to a [bad imo] programming style to
	overcome the bug] but it introduced a dual semantic for define-method and
	breaks this fundamental [language designed] rule: "... If they can apply to
	instances of a class C, they can also apply to instances of subclasses of
	C..."

Cheers,
David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]