Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: 2008-02-21 (13:39)
From: Remi Vanicat <vanicat@d...>
Subject: Re: OO programming
Tiphaine Turpin <> writes:

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

something like that might work (from the Dider Remy example)

class ['observer] subject =
object (self : 'mytype)
  val mutable observers : 'observer list = []
  method add obs = observers <- obs :: observers
  method notify (message : 'observer -> 'mytype -> unit) =
    List.iter (fun obs -> message obs self) observers

class ['subject] observer =
  constraint 'subject = 'a #subject

Note that it doesn't solve completely the problem (as #subject is
still an open type) but it might catch some problem.

Rémi Vanicat