First, thank you for your detailed answer! On 28 July 2016 at 22:14, David Pirotte <[email protected]> wrote: > First, generic functions are 'containers', that are not associated, and do not > pertain to any class. <a> does not have a generic function x:
Thank you, I am still thinking in Java terms at the moment. > 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. 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 function on the set elements, such that for any call to the function with an element of the set, the result will also be in the set. This is the same code for all implementation, but depends on implementation specific code such as "contains?" and "add". Then I want to implement different sets, e.g. red-black trees, AVL trees, etc. The plan was something like this, but I think I may be trying to achieve it wrong, or at least the unidiomatic way: ; <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 ... ) ; <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>)) ...) ; <mbe/test.scm>= ... Code to exercise methods ... > But if you do so, define generic functions manually, then I recommend do it in > another module. So I could move the add, etc, methods out into another module, if that is the way to do it, but I need them, because without having them, 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.
