Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a <clutter-actor> subclass

[David Pirotte <david@altosw.be>]

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

Andy,

> Are you certain?  What git revision are you using?  I don't think the
> test should "work" with the current stable-2.0 or master, or 1.8 for
> that matter.

>     $ /opt/guile-1.8/bin/guile
>     guile> (use-modules (oop goops))
>     guile> (define-class <a> ()
>     ...    (width #:accessor width #:init-keyword #:width #:init-value 0))
>     guile> (define-class <b> (<a>))
>     guile> (define b (make <b>))
>     guile> (width b)
>     0
>     guile> (set! (width b) 10)
>     guile> (width b)
>     10
>     guile> (define-method ((setter width) (self <b>) width) (next-method))
>     guile> (set! (width b) 10)
> 
>     Backtrace:
>     In current input:
>       10: 0* [setter:width #<<b> 7f795ed527e0> 10]
>        ?: 1  (let* ((next-method (goops:make-next-method self width)))
> (next-method))
> 
>     <unnamed port>: In expression (let* (#) (next-method)):
>     <unnamed port>: No next method when calling #<<generic> setter:width (2)>
>     with arguments (#<<b> 7f795ed527e0> 10)
>     ABORT: (goops-error)

When talking about goops, we should not refer to 1.8 (*), 1.6 or any guile version
for that matter, but to the clos language spec subset goops implements [appart from
the adaptation for it to be module protected, but that is not the point here].

This said and with that in mind, the implementation you say was in guile-1.8 and
that it appears you have reimplemented 'right now' breaks the specification and
afaiac makes goops totally unusable for any serious work: this is a catastrophy,
please reconsider!

	-] anything defined by a user using define-method _must_ pass thought the
	exact same computation machinery _and_ all become applicable methods;

	-] within the core of a define-method, one must always be able to call
	(next-method) [of course if the user do so inappropriately it raises an
	error, I'm not talking about that];

	-] they is no exception for setters, which are _just_ methods, with, in
	addition and as we know, a bit of 'magic' so that they can be used with set!
	
		-> otherwise, there would be 2 define-method semantics
		-> that can't be, and if it was the case the clos 'comity' would
		have defined another method for setters such as
		define-setter-method, and restrict that method from being able to
		call (call-next-method);

	-] within the core of methods, including the ones called with (next-method)
	calls to slot-ref slot-set! must _always_ call the instance(s) slot-ref-
	slot-set! as defined by the system [if none were provided], or the user's
	code they were provided [such as when #:allocation is #:virtual]

We should not need any really, but here is a description [no code, no need to at
this point] of a [still very simple] 'visual' example, so everyone can follow:

	let's define a gravity sensitive class <apple> and a !gravity setter, which
	sets the position of the instance on a scene and takes care of its layout
	[as in 'horizontal or 'vertical] depending on the gravity poles the instance
	respond to: at some point this setter method calls sot-set! to set the
	instance position slot value, such as 'north-west;

	then we define a <toolbar> class, which inherit from <apple>, with
	an item slot filled with <button> instances, each button having an optional 
	<tooltip> instance [a text, "My beautiful tooltip..."];

	each tooltip text must 'glue' to there button _and_ always be entirely on the
	scene [visible to the user, if the scene is itself visible of course, but
	that's not the question here]:

	-> that means there is extra work to be done on toolbar instances, but we
	want to run the <apple> !gravity setter code first

	(define-method ((setter !gravity) (self <clus-toolbar>) gravity)
	  (next-method)
	  (for-each (lambda (toolbar-item)
		      (ensure-tooltips-on-stage toolbar-item))
	    (!items self)))

Cheers,
David

(*) Besides, let me tell you that I never intensively used goops before guile-2, but
just played a little with it, precisely because I could not trust it, as I had my
heisen bugs using guile 1.6 because in these past times I could not even trust the
module system




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