Re: [Caml-list] OO programming

[Keiko Nakata <keiko@kurims.kyoto-u.ac.jp>]

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

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

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. 

Best, 
Keiko