Browse thread
OO programming
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Tiphaine.Turpin <Tiphaine.Turpin@f...> |
| Subject: | Re: [Caml-list] OO programming |
Keiko Nakata a écrit : >>> Since there are some people (including me) >>> who are interested in using functors and recursive modules >>> in the style of object-oriented context, >>> >>> >> Do you mean including classes in functors, as Jacques Garrigue >> described, or using modules like classes ? >> > > The former; to include classes in functors. > > >>> I thought that it could be useful to devise >>> a (camlp4) syntax extension which mitigates this a bit painful verbosity. >>> >> camlp4 extensions may help. I already used some for objects (related to >> initializers), and I plan to investigate it further, possibly borrowing >> code from Jacques Garrigue. In the context of functors, the problem is >> that a lot of code would probably remain specific and still need to be >> written by hand, for example, the row types for classes... >> > > As I see Jacques's code, he gradually extends the module type S > to S' and S''. Type declarations in module types and type definitions > in structures involving types event, observer and subject are duplicated > everywhere with slight modifications. > Why can we not extend the previously defined module type > in a less verbose way? > I agree. Maybe the idea of using parametric class type definitions (in WRichT) and defining unparameterized types afterwards (in S'') could be helpfull, as such definitions can be extended with the "inherit <class-type>" construct. Otherwise you would need to keep syntaxically the successive declarations with camlp4 for future use, which is not very handy. I don't know if there is an equivalent to inherit for polymorphic variants: "type t' = private [> t | ...] doesn't seem to work. And using objects to encode variants is possible, but you may be used to more serious solutions... Tiphaine Turpin > We may still need to write row types by hand. > But I think we should (ideally) do it in a extensible way without duplications. > > With best regards, > Keiko > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >