Re: Modules and GOOPS

[David Pirotte]

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.

pgpkrlgKRS4r7.pgp
Description: OpenPGP digital signature