From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id A9919BBC1 for ; Thu, 21 Feb 2008 10:35:44 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.25,385,1199660400"; d="scan'208";a="8371657" Received: from arvin.irisa.fr (HELO [131.254.11.86]) ([131.254.11.86]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Feb 2008 10:35:44 +0100 Message-ID: <47BD44FE.3050001@irisa.fr> Date: Thu, 21 Feb 2008 10:31:42 +0100 From: Tiphaine Turpin User-Agent: Thunderbird 1.5.0.10 (X11/20070303) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: OO programming Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; irisa:01 ocaml:01 typecheck:01 subtyping:01 mutable:01 parametric:01 subtype:01 didier:01 parametric:01 dependencies:01 type-checker:01 type-checker:01 recursive:01 modular:01 unsatisfied:98 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.