Version française
Home     About     Download     Resources     Contact us    
Browse thread
OO programming
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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
>