Re: Modules and GOOPS

[David Pirotte <david@altosw.be>]

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

Hello,

> First, thank you for your detailed answer!

Welcome

>  So what is the right approach when I'm implementing textbook data
> structures (rather than want to use the given ones, for learning
> reasons) and want to implement a set. On this set, I want to write a
> method "closure" that computes all the elements of the set given a
> ...

I won't have time to help you to design the all thing, but i can review
small and complete (no ...) code snipset. The code below is incomplete.

> ; <sets/set.scm>=
> (define-module (sets set)
>   #:use-module (oop goops)
>   #:export (<set> add ... closure))
> 
> (define-class <set> ())
> 
> (define-generic add)
> ...
> 
> (define-method (closure (set <set>) (function <proceedure>))
>   ... contains? ... add ... )

this is indeed not a very good design, imo: the fact that your <set> is an 'empty'
class, and with no applicable methods for the all the methods it calls in closure,
are the symptoms, imo, that this is not a good design

> ; <sets/red-black-tee-set.scm>=
> (define-module (sets red-black-tree)
>   #:use-module (oop goops)
>   #:use-module (sets set)
>   #:export (<red-black-tree>))
> 
> (define-class <red-black-tree> (<set>))
> 
> (define-method (add (tree <red-black-tree>))
>   ...)

I can only give an opinion, and it is only an opinion, if you provide full code
snipset: and your add method lacks an argument to add :)

> So I could move the add, etc, methods out into another module, if that
> is the way to do it

Nope, I did not say that, I did say that if you want to manually define generic
functions, then do it in a separate module, and imports that module when
necessary.

Although not strictly necessary technically speaking, we generally define methods in
the same module as the one where the class of its first argument (used to dispatch)
is defined. Just look at some of the clutter examples (links i previous email)...

> Guile will complain with "unbound variable: add". But this is a very
> classes-contain-methods approach and given what you said, makes me
> think that I'm doing this wrong thing.

The fact that you manually define the generic function "add" gives the 'illusion' the
design is good, but in fact, (add (make <set>) <element>) will fail with no
applicable method, which imo, is a sign that the¬this design is not good.

The fact that the GF definition is in the (sets set) module does not make the design
any better. If you persist in manually defining GF, do it in another module, that
all other module which needs them imports of course ...

David.






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