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=1.0 required=5.0 tests=AWL,SPF_FAIL 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 B1517BBC1 for ; Thu, 21 Feb 2008 14:39:27 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMINvUfAXQImh2dsb2JhbACQXQEBAQgKKYEUnWM X-IronPort-AV: E=Sophos;i="4.25,386,1199660400"; d="scan'208";a="8383555" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 21 Feb 2008 14:39:27 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1LDdQ6B024979 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 21 Feb 2008 14:39:27 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAE4OvUdQW+UCh2dsb2JhbACQXQEBAQgKKYEUnWE X-IronPort-AV: E=Sophos;i="4.25,386,1199660400"; d="scan'208";a="9426759" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Feb 2008 14:39:08 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JSBdf-0001Db-5E for caml-list@inria.fr; Thu, 21 Feb 2008 13:39:03 +0000 Received: from 93.71.103-84.rev.gaoland.net ([84.103.71.93]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 13:39:03 +0000 Received: from vanicat by 93.71.103-84.rev.gaoland.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 13:39:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Remi Vanicat Subject: Re: OO programming Date: Thu, 21 Feb 2008 14:38:53 +0100 Organization: none Message-ID: <87myputonm.dlv@maison.homelinux.org> References: <47BD44FE.3050001@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93.71.103-84.rev.gaoland.net Mail-Copy-To: never User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:SLGoN1XzJS3ArAtmZ9DHWqB1d7c= Sender: news X-Miltered: at discorde with ID 47BD7F0E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! 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 val:01 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 : > > 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