[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Modules and GOOPS
From: |
David Pirotte |
Subject: |
Re: Modules and GOOPS |
Date: |
Thu, 28 Jul 2016 18:14:25 -0300 |
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