Re: [Caml-list] OO programming

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

Dirk Thierbach a écrit :
> I am not interested in doing something
> just because eomeone tells me, possible mistakenly, that I have to
> follow "the" paradigm.
>   
I won't blame you for that. I'm not either :-). The few (2-3) programs 
of "not-toy" size that I did using objects (either in Java or in Ocaml) 
both extensively used many linked objects implementing lots of methods 
in a mutually recursive way, so I consider this an crucial features of 
objects. And really, I code things the way I think I'm able to do them 
the best (I have the chance that my programs only need to look nice to 
me): I do what I can. I choose functional or imperative style according 
to my best understanding of the domain, or objects (in Ocaml, I consider 
objects only if I think that I cannot achieve my goals in a satisfactory 
way with functions).

>   
>>> 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.
>>     
>
> Mutual recursive classes won't solve this problem at all.
Yes it does, I think (wether it's a good way of solving it is 
debatable). If you declare the classes generating events together with 
classes that handle them, and if it appears (in the declaration, which 
is where fields are usefull) that the method used in the generating 
objects will be invoked on the handler objects, then the types of the 
two methods will need to be compatible. Of course, in your example, you 
would probably want to use either a class type for handler objects, or 
have them inherit from a virtual handler class that declare the type of 
the method once and for all. My point is that using in one of the 
classes the type associated with the other class for one of its fields 
(and invoking methods on that fields) puts the necessary constraints to 
free you from many declarations (mutual recursive classes are actually 
only needed if you want links in both directions, which is not 
necessarily the case of your example, I agree).


>  Maybe an 
> example helps: In a GUI, one can get various sorts of events, say,
> a "resize" event. If the method connected to that event is only
> interested in the new width and not in the height, so it doesn't
> use this value at all, you have to declare the type. No other class
> involved at all.
>   
>> 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.
>>     
>
> If you manage to find a simple type system for that, preferably with
> type inference and principal typings, I'd like to see it :-)
>   
I wish I could do that in Ocaml...

>> 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.
>>     
>
> So maybe there's a reason they are doing it differently. :-)
They aren't doing differently. They're just not treating an exhaustive 
list of the software architecture problems that people may encouter (or, 
pose to themselve). Which does not scandalize me in itself ;-).


Tiphaine Turpin