Re: [Caml-list] OO programming

[Tiphaine Turpin <Tiphaine.Turpin@irisa.fr>]

Keiko Nakata a écrit :
>>> 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. 
>>     
>
> Parametric class type definitions should be helpful.
> We might need as many type parameters as (class) type definitions involved;
> do you think this can be problematic, 
> particularly in respect of type error messages?
>   
Only experiments can tell us. But I suspect that using a systematic 
scheme for defining classes and relating them to each other should avoid 
users to make too many errors that come from a misunderstanding of the 
type system ('self escaping its scoope, or unified wit a closed type, 
etc.), thus allowing "advanced" use of caml objects by non type systems 
experts (including me).
> Hopefully we want to start with S and 
> derive its refinements by extending S bit by bit. 
> But here is one problem: module type declarations (e.g. S) and 
> structures (e.g. WindowA) are completely different entities;
> it can be handy in practice if we can include S in WihdowA 
> and refine the included types by giving concrete representations
> to abstract types (e.g. event).
>
> Well, I know that module types and structures are 
> indeed completely different 
> from the theoretical point of view....
>   
In this case where they are only made of (the same) types with a class 
type on one side and a private row type on the other side, this 
theoretical difference is far from obvious in practise, and this is one 
of the reasons why such code is so hard to read (as the same thing seem 
to be repeated twice). This would be nice if you could write your types 
once (possibly in a very small subset of the type language) and have the 
module and the module type be generated from the same code.
> Here is another thing that may be worth attention.
> The types observer and subject in WRichT are not recursive, 
> but we take their fix-point in S''. 
> Unfortunately we cannot do this kind of refinement 
> via the "with" construct. 
>
> Anyway, I think we are almost exactly following OO-programming style
> in a more explicit thus more verbose way. 
> So I conjecture that if we come up with good syntactic sugar, 
> we can be as concise as OOP; as you suggest it may well be 
> a good idea to expand the sugar into parametric class definitions, 
> possibly combined with functors and private row types to increase modularity. 
>   
I plan to do some reasonable scale "OOcaml" coding (in my spare time) 
for some project. I will first see if I can use some systematic scheme 
successfully before I try anything with camlp4. That said, some of us 
tend to think of everything only from within ocaml, and I know that some 
day I should give a try to other systems, like Scala and its "traits".

Tiphaine Turpin

> Best, 
> 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
>
>