On Mon, 2004-06-14 at 19:29, François-Xavier HOUARD wrote:

> But the answer you gave me, which I find quite nice, don't allow my user
> to add his own class....

They would have to edit the module to do it, but they
can do it.

Here is another solution: visitor pattern.

class 'w window = object (self)
  val mutable childs: 'w list
  ...
  method iter (f:'w -> unit) =
    List.iter f childs
end

... user now can write:

type 'w mywidgets' = [`A of 'w a_kind' | `B of 'w b_kind' .. ] 

class ['w] a_kind' = object .....
class a_kind = widget a_kind' ...

etc etc as before. Now the *user* must unify all the types
with a variant, but the class doesn't need to know
what is is until it is instantiated.

One way or the other there is no alternative to unifying
all the widget types with a sum (variant) or an abstraction
(class supertypes) or both.

Typical GUI like GTK do both (there are run time
tests for kinds of widgets, so you can do button
specific things on any kind of button etc).

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners