Re: Modules and GOOPS

[David Pirotte <david@altosw.be>]

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

Hello,

Before anything else, note that I speak on my own behalf here, not in the name of
Guile. I'm saying this because I have an opinionated opinion about Goops, its actual
'design/problems/limitations/bugs' [depending of your point of view], why and how we
should change this, as well as how users should use it, precisely regarding, but not
limited to, generic functions and the module system, among other things.

> I have trouble with getting GOOPS and modules to co-operate. What I am
> trying to do is to have 'A subclass B' where A is something akin to an
> abstract class, that is it has generic "x" for which it provides no
> implementation. This is my minimum broken example:

First, generic functions are 'containers', that are not associated, and do not
pertain to any class. <a> does not have a generic function x:

	obviously, this _is_ the beauty (and one of the reason why it's been design
	this way) since this way, the entire knowledge, except for slot-ref and
	slot-set! [1] of a generic function multi method polymorphic dispatch system
	is in user methods and procedures called by these methods;

	this means, unlike it's been said on this ML several time, unless you use
	slot-set! (same for Guile set!, no diff wrt Goops here) and  class
	redefinition, Goops is perfectly 'compatible' with functional programming;

	[1] same problem for define-record, which are not more neither less
	'functional' then Goops, imo.

Then unlike you've been told by others, I do not recommend to define generic
function, they are just 'containers', the system creates them for you and it is an
error [not implemented by Guile] to redefine a generic function. With the last in
mind, manually defining GF will work if you play with a couple of your own modules,
but it will almost certainly fail for large system.

But if you do so, define generic functions manually, then I recommend do it in
another module.

> ; <mbe/a.scm>=
> (define-module (mbe a)
>   #:use-module (oop goops)
>   #:export (<a> x y))
> 
> (define-class <a> ())
> 
> (define-generic x)
> (define-generic y)
> 
> (define-method (y (a <a>))
>   (display (x a)))
> 
> ; <mbe/b.scm>=
> (define-module (mbe b)
>   #:use-module (oop goops)
>   #:use-module (mbe a)
>   #:export (<b> x))

It will work if you #:re-export (x):

	#:export (<b>)
	#:re-export (x))

But that not good enough, imo. We precisely _do not_ want to know if we have to use
#:export or #:re-export, what we want here is the system to do that for us. I wrote
a macro which does the check 'if-exists' for us and either #:export or #:re-export
adequately, it's here, fell free to use it:

	http://git.savannah.gnu.org/cgit/grip.git/tree/grip/g-export.scm

You should use it _only_ for getters, setters, accessors and methods, obviously!

 	here is an example of use

	http://git.savannah.gnu.org/cgit/grip.git/tree/grip/clutter/grid.scm

Make sure your class names are unique i the entire 'system' and always use #:export
<class name>: this will always create a fresh new binding, and so, unlike in CLOS,
won't trigger a class redefinition if it would need to.  This said, unless you
really know what you're doing, or for pure experimental reasons, don't write
'production' code that rely on class redefinition.

> (define-class <b> (<a>))
> 
> (define-method (x (b <b>))
>   'b)
> 
> ; <mbe/test.scm>=
> (define-module (mbe test)
>   #:use-module (oop goops)
>   #:use-module (mbe a)
>   #:use-module (mbe b)
>   #:duplicates (merge-generics))

You should add merge-generics to the default handlers:

	scheme@(guile-user)> (default-duplicate-binding-handler)
	$5 = (replace warn-override-core warn last)

So you'd have 

	#:duplicates (merge-generics replace warn-override-core warn last)

Note that you still have to set these in your repl (and any script of yours), if you
import more then 1 module defining a GF.  Here is an example of script:

	http://git.savannah.gnu.org/cgit/grip.git/tree/grip/clutter/examples/bouncer.in
	
		[ line 38 - 41

Also note that in Guile-2.0, module definitions (ice-9/boot.scm
define-modules* macro) were calling (default-duplicate-binding-handler), so it
was not necessary to declare #:duplicates in each module. This great global
parameter setting, and API IMO, has been withdrawn in Guile-2.2, which hard codes
duplicate handlers 'as in the manual'.

David.

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