Re: [Caml-list] OO programming

["Tiphaine.Turpin" <Tiphaine.Turpin@free.fr>]

Dirk Thierbach a écrit :
> On Thu, Feb 21, 2008 at 10:31:42AM +0100, Tiphaine Turpin wrote:
>   
>> The usual problem is that objects refer to other objects, 
>>     
>
> I avoid this as much as possible.
No connecting of objects, therefore no mutually recursive methods, (and 
many arguments added to every function to carry the missing context), 
little mutable state, and no use of class names to specify types... I'm 
sure that many problems go away in this setting, and there are still 
advantages to using objects (inheritance, etc.) but isn't this a 
somewhat degraded version of the object paradigm ?

>  Instead of "connecting" objects
> to other objects, I "connect" an objects to "actions" (functions),
> which may be closures that include other objects. The typical example
> which has already been given is the observer-pattern, which I use
> as follows:
>
> class ['a] observer = 
> object(self)
>   val mutable actions = []
>   method register action =
>     actions <- action :: actions
>   method notify (arg : 'a) = 
>     List.iter (fun f -> f arg) actions
> end;;
>
> No class for subject needed. Many of the objects I use in the GUI layer 
> just inherit from observer, and it's also handy if the action you want
> doesn't refer to an explicit object in the OCaml layer (because the
> state is kept in the external GUI layer)
> [...]
>   
> Much more annoying is that one also has to give types to arguments in
> methods that are unused (they are present make them compatible with
> another class, which uses them;
which is where I think mutually recursive classes would be usefull, if 
their typing was easier.
>  or they are required by the GUI
> layer), and that OCaml has now way to seperate method/function
> declaration and type declaration (unless one uses a mli file, which is
> again inconvenient because it splits information that belongs together
> into two complete different places). I'd really appreciate it if one
> could just mix "val" type declcarations with "let" or "method" code
> declarations.
>   
I don't understand what you want here.
>   
>> Of course, the resulting classes should be reusable, that is, one
>> should be able to extend a collection of related classes
>> simultaneously, such that the fields now have the relevant subtype
>> instead of the type they had before.
>>     
>
> Not sure what exactly you mean here. Could you give an example?
>   
I will try to state at an abstract level what I would like to do :

- define parametric virtual classes A and B so that every A has a Bs 
(one or many...) and vice-versa.
- possibly extend A and B to A' and B' respectively, so that every A' 
has B's (and not just Bs), etc.
- subtyping: possibly extend B to B1 and B2 so that their objects have 
As, but those As still have Bs, so that I can associate the same A to 
objects of class B, B1 or B2.

- and the ultimate goal combining all that: define A and B as above, 
other virtual classes C and D in a similar way and E and F too, and 
define concrete classes X Y Z1 Z2 just by saying that X extends A, Y 
will play the role of B in the first two classes and the role of C in 
the last two ones, and Z1 Z2 extends D (both) and E and F 
(respectively). It happens that some of the types that were left 
parametric (respectively methods defined as virtual) in B are made 
concrete in C, (and so on), so I obtain my final concrete classes.

Finally, I want the typing to be done step by step, so that for example 
the incompatibilities that exist already between A and B are detected 
independently of the rest.

I understand that what I'm asking for is a lot. The subtyping is 
especially problematic, and I begin to wonder if it's not related to the 
famous cases of inheritance that do not imply subtyping...

For now, I found many introductions on ocaml objects using and how to 
actually use them (Ocaml manual, Didier Remy's course, the "Developing 
applications with Objective Caml" book, as suggested by Julien Moutinho, 
and also Philippe Narbel's book) but none of them went that far.

Tiphaine Turpin