Re: OO programming

[Remi Vanicat <vanicat@debian.org>]

Tiphaine Turpin <Tiphaine.Turpin@irisa.fr> 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 :
>
> 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 ?

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
end;;

class ['subject] observer =
object
  constraint 'subject = 'a #subject
end;;

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