[Top][All Lists]

[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: Sat, 30 Jul 2016 23:35:44 -0300


> First, thank you for your detailed answer!


>  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 
class, and with no applicable methods for the all the methods it calls in 
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

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 
is defined. Just look at some of the clutter examples (links i previous 

> 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 
any better. If you persist in manually defining GF, do it in another module, 
all other module which needs them imports of course ...


Attachment: pgpSLFMoyoJmH.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]