bug#20423: goops - inheritance of slot options

bug#20423: goops - inheritance of slot options

[David Pirotte]

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

Hello,

	GNU Guile 2.0.11.114-649ec
	goops - inheritance of slot options
	severity - serious

The current goops implementation breaks the [clos] protocol [*] for inheritance of
slot options.  This is a serious bug.

Below, [A] what stklos does, [B] what goops does, [*] a summary of what the clos
protocol says wrt  inheritance of slot options.

Cheers,
David


[A]	Here is what stklos does:

	stklos/subclass-slot-redefinition.scm

--8<---------------cut here---------------start------------->8---
(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")))
--8<---------------cut here---------------end-------------->8---

david@capac:~/alto/projects/stklos 15 $ 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> 28a2420] is an an instance of class <maths-teacher>.
Slots are: 
     age = 34
     name = john
     subject = "Mathematics"
stklos> (subject p2)
"Mathematics"
stklos> 


[B]	Here is what goops does:

	goops/subclass-slot-redefinition.scm

--8<---------------cut here---------------start------------->8---
(use-modules (oop goops))

(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"))
--8<---------------cut here---------------end-------------->8---

david@capac:~/alto/projects/guile-tests/goops 51 $ guile
GNU Guile 2.0.11.114-649ec
Copyright (C) 1995-2014 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (load "subclass-slot-redefinition.scm")
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /usr/alto/projects/guile-tests/goops/subclass-slot-redefinition.scm
;;;
compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/subclass-slot-redefinition.scm.go
scheme@(guile-user)> (define p2 (make <maths-teacher> #:name 'john #:age 34))
scheme@(guile-user)> ,use (oop goops describe) scheme@(guile-user)> (describe p2)
#<<maths-teacher> 1432300> is an instance of class <maths-teacher>
Slots are: 
     name = john
     age = 34
     subject = "Mathematics"
scheme@(guile-user)> (subject p2)
ERROR: In procedure scm-error:
ERROR: No applicable method for #<<accessor> subject (1)> in call (subject
#<<maths-teacher> 1432300>)

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


[*] A summary of what 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.)

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

bug#20423: goops - inheritance of slot options

[Andy Wingo]

Hi,

For what it's worth this is a part of GOOPS's design AFAIU: all slot
definitions are unique.  Two slots named S declared on classes A and B
are distinct, even if A is a superclass of B.

I don't know if we can change this.  I guess maybe.  There would have to
be a design though.  I guess fleshing out the `compute-slots' protocol
from http://www.alu.org/mop/concepts.html#class-finalization-protocol
would be the thing.

I believe that technically you can already provide your own
`compute-slots' implementation, but you are probably missing some
definitions that would help you do so in a compatible manner.  Check it
out for yourself and give it a go, no need to wait on Guile people :)

Andy

On Sat 25 Apr 2015 04:05, David Pirotte <david@altosw.be> writes:

> Hello,
>
> 	GNU Guile 2.0.11.114-649ec
> 	goops - inheritance of slot options
> 	severity - serious
>
> The current goops implementation breaks the [clos] protocol [*] for inheritance of
> slot options.  This is a serious bug.
>
> Below, [A] what stklos does, [B] what goops does, [*] a summary of what the clos
> protocol says wrt  inheritance of slot options.
>
> Cheers,
> David
>
>
> [A]	Here is what stklos does:
>
> 	stklos/subclass-slot-redefinition.scm
>
> (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")))
>
> david@capac:~/alto/projects/stklos 15 $ 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> 28a2420] is an an instance of class <maths-teacher>.
> Slots are: 
>      age = 34
>      name = john
>      subject = "Mathematics"
> stklos> (subject p2)
> "Mathematics"
> stklos> 
>
>
> [B]	Here is what goops does:
>
> 	goops/subclass-slot-redefinition.scm
>
> (use-modules (oop goops))
>
> (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"))
>
> david@capac:~/alto/projects/guile-tests/goops 51 $ guile
> GNU Guile 2.0.11.114-649ec
> Copyright (C) 1995-2014 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (load "subclass-slot-redefinition.scm")
> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;;       or pass the --no-auto-compile argument to disable.
> ;;; compiling /usr/alto/projects/guile-tests/goops/subclass-slot-redefinition.scm
> ;;;
> compiled /home/david/.cache/guile/ccache/2.0-LE-8-2.0/usr/alto/projects/guile-tests/goops/subclass-slot-redefinition.scm.go
> scheme@(guile-user)> (define p2 (make <maths-teacher> #:name 'john #:age 34))
> scheme@(guile-user)> ,use (oop goops describe) scheme@(guile-user)> (describe p2)
> #<<maths-teacher> 1432300> is an instance of class <maths-teacher>
> Slots are: 
>      name = john
>      age = 34
>      subject = "Mathematics"
> scheme@(guile-user)> (subject p2)
> ERROR: In procedure scm-error:
> ERROR: No applicable method for #<<accessor> subject (1)> in call (subject
> #<<maths-teacher> 1432300>)
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]> 
>
>
> [*] A summary of what 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.)

bug#20423: goops - inheritance of slot options

[David Pirotte]

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

Hi Andy,

> For what it's worth this is a part of GOOPS's design AFAIU: all slot
> definitions are unique.  Two slots named S declared on classes A and B
> are distinct, even if A is a superclass of B.

Well, as I explained in the original report, the only specification we have is CLOS:
Stklos, upon which Guile GOOPS is based, clearly state in its manual, among the
first paragraphs, that it implements the CLOS protocol [a subset]: there is no
'redesign' anywhere in Stlkos [it just lacks :before and :after methods AFAICT].

AFAICT, there is no Guile 'official' document stating clearly, neither in the
manual, that GOOPS authors decided to redesign this part of the protocol and why...
is there?

It seems to me, in this rather unfortunate case, that you take for a 'design' or a
'redesign', what was actually a great implementation to start with, no doubt, but
which has these bugs, implementation bugs, not design decisions.

> I don't know if we can change this.  I guess maybe.  There would have to
> be a design though.  I guess fleshing out the `compute-slots' protocol
> from http://www.alu.org/mop/concepts.html#class-finalization-protocol
> would be the thing.

Not sure what you mean by 'we can't change this', but I hope/think it can be fixed,
technically I don't see what could prevent this to be done since Stklos does the
right thing... [I'm pretty sure gauche does the right thing too, and in any case,
all CLOS implementation do]. Maybe you are referring to some C part of the code I'm
not aware of that would effectively prevent a fix, don't know...

> I believe that technically you can already provide your own
> `compute-slots' implementation, but you are probably missing some
> definitions that would help you do so in a compatible manner.  Check it
> out for yourself and give it a go, no need to wait on Guile people :)

	Right: if you want it right do it yourself ... :) 

It actually is my intention, it has been for years, to study, dig into and work on
our GOOPS implementation and start to help maintain it ... if I only had more time,
I would have done it already.

Till then we rely on you, And even though I could do it 'right now' we'd still have,
unless selfish my own implementation in my little corner, still have to agree upon
the design reference document(s) GOOPS has been/should be based  upon:

	and I want GOOPS to follow the CLOS protocol, for its entire subset, not just
	for me, but any Guilers, and especially the one that will learn oop using
	GOOPS;

	the above, especially for getters, setters, accessors inheritance _and_ this
	bug, slot redefinition.

So, rather then being a technical problem, we strongly disagree, unfortunately, on
what GOOPS protocol should implement, don't you think it would be better to follow
the CLOS protocol?

	Could you list what you consider a win, for humanity :), in blocking slot
	option redefinition and inheritance to be blocked?

	Could we talk to the original GOOPS author, and if so, would you be
	convinced, if he confirms of course, that all these are bugs and not design
	decisions?

All this said, I wonder, before I start :), if the still C part of the code would
prevent me to patch GOOPS so it fully respect the CLOS protocol?

Thanks,
David

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

bug#20423: goops - inheritance of slot options

[dsmich]

---- David Pirotte <david@altosw.be> wrote: 
> Hi Andy,
> 
> > For what it's worth this is a part of GOOPS's design AFAIU: all slot
> > definitions are unique.  Two slots named S declared on classes A and B
> > are distinct, even if A is a superclass of B.
> 
> Well, as I explained in the original report, the only specification we have is CLOS:
> Stklos, upon which Guile GOOPS is based, clearly state in its manual, among the
> first paragraphs, that it implements the CLOS protocol [a subset]: there is no
> 'redesign' anywhere in Stlkos [it just lacks :before and :after methods AFAICT].
> 
> AFAICT, there is no Guile 'official' document stating clearly, neither in the
> manual, that GOOPS authors decided to redesign this part of the protocol and why...
> is there?

Way way back, goops was a separate project from guile.   This TODO file has some info on where Mikael was planning on going with it:

http://cvs.savannah.gnu.org/viewvc/guile/guile-oops/TODO?revision=1.19&root=guile&view=markup

-Dale

bug#20423: goops - inheritance of slot options

[Andy Wingo]

Hi,

On Fri 24 Jun 2016 01:08, David Pirotte <david@altosw.be> writes:

> It actually is my intention, it has been for years, to study, dig into and work on
> our GOOPS implementation and start to help maintain it ... if I only had more time,
> I would have done it already.
>
> Till then we rely on you

I don't have any time to devote to this, sorry :/

Regards,

Andy

bug#20423: goops - inheritance of slot options

[David Pirotte]

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

Hi Andy,

> > It actually is my intention, it has been for years, to study, dig into and work
> > on our GOOPS implementation and start to help maintain it ... if I only had more
> > time, I would have done it already.

> > Till then we rely on you  

> I don't have any time to devote to this, sorry :/

By 'we rely on you', I was referring to maintaining goops, which you do perfectly
well, thanks!: but you are maintaining an 'hybrid system' with no design, believing
it has, but that's not the case.

Personal notes  and an implementation are not, AFAIC, and far from being, a
'design'.  Besides, with all due respect to the person(s) and his/her technical
abilities, it is obvious to me that he/her/they lack(s) a profound understanding of
the domain, and hence this 'hybrid system' we have now breaks fundamental parts of
the protocol it was [and still is, imo] supposed to follow. It breaks these
fundamental parts of the protocol for no good reason, not a single one, and the
result is an order of magnitude inferior to what it could/should be.

I also strongly believe these issues are actually easy to fix, for you, who
deeply knows the implementation and recently fully reviewed it's source code, so I
don't believe time is the problem here: we disagree on what Goops was originally
meant to be and should be, and right now, I failed to convinced you to revisit your
position, in the light of the above, the official design [clos], what Stklos and
early Goops did implement.

Too bad, because it is the right thing to do, for the good of all guilers, not just
me: this is why I spend my time still trying to convince you that what we have is
not good, and this is not good for Guile, imo.

For users, this issue is easy to 'fix': just copy paste the slot def and locally
change what ever you need to change: 'un plâtre sur une jambe de bois', but at
least it's easy to overcome this current limitation.

Wrt this issue, Stklos and 'early' Goops was following and still should follow this
design:

> [*] A summary of what 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.)  

Cheers,
And thanks for the hard work anyway!
One day we will agree, I sincerely hope so, for the good of Guile.
David


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

bug#20423: goops - inheritance of slot options

[Andy Wingo]

Hi,

On Fri 24 Jun 2016 01:08, David Pirotte <david@altosw.be> writes:

> It actually is my intention, it has been for years, to study, dig into and work on
> our GOOPS implementation and start to help maintain it ... if I only had more time,
> I would have done it already.
>
> Till then we rely on you

I don't have any time to devote to this, sorry :/

Regards,

Andy