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@i...>
Subject: OO programming
Hello,

After a few unsuccessfull tries with using the object oriented features 
of ocaml, I have been looking for ways to write classes that have a 
chance to typecheck. The usual problem is that objects refer to other 
objects, those objects may refer back to objects referring to them, then 
objects refer to different objects, some of them having more methods 
than others (subtyping), etc. and finally the programmer has to give a 
type to all those beautifull mutable fields that are not fully 
specified, or make them parametric. 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.

The best guidelines that I found are in the following course from Didier 
Remy :

http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-objects.html#toc13

He uses parametric classes  (parametric in the type of the related 
objects) so that they can be extended. However I'm still unsatisfied 
with this solution, because the related classes are written 
independently, or, more precisely, their dependencies remain in the head 
of the programmer and have no concretization in the language. For 
example if a class refer to a method provided by a related class, this 
way of writing them does not guarantee that the method is actually 
defined. Only when creating and linking the objects together will the 
type-checker reject the program, if for example, the method has been 
misspelled in one class. So for me this coding scheme has the drawback 
that it unplugs the type-checker and just call it at the end. For me the 
"ideal" use of objects would use mutually recursive classes with fields 
defined with a type referring to the name of the other class. The 
problem is that simply using the closed type of the other classs often 
prevent any further refinement.

Hence my question: does anyone knows a way of combining the reusability 
of sets of related classes with a more modular (type/consistency)-checking ?

Tiphaine Turpin

P.S. : Sorry for not providing any example myself ; the above link has 
very clear ones, that express exactly what I mean.