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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id E09BDBBCA for ; Mon, 25 Feb 2008 10:27:15 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.25,400,1199660400"; d="scan'208";a="7653936" Received: from arvin.irisa.fr (HELO [131.254.11.86]) ([131.254.11.86]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Feb 2008 10:27:12 +0100 Message-ID: <47C288FD.8070602@free.fr> Date: Mon, 25 Feb 2008 10:23:09 +0100 From: "Tiphaine.Turpin" User-Agent: Thunderbird 1.5.0.10 (X11/20070303) MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OO programming References: <47BD44FE.3050001@irisa.fr> <20080224163308.GA3459@feanor> In-Reply-To: <20080224163308.GA3459@feanor> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam: no; 0.00; 0100,:01 recursive:01 mutable:01 val:01 mutable:01 iter:01 ocaml:01 recursive:01 ocaml:01 mli:01 val:01 subtype:01 parametric:01 vice-versa:01 subtyping:01 Dirk Thierbach a écrit : > On Thu, Feb 21, 2008 at 10:31:42AM +0100, Tiphaine Turpin wrote: > >> The usual problem is that objects refer to other objects, >> > > I avoid this as much as possible. No connecting of objects, therefore no mutually recursive methods, (and many arguments added to every function to carry the missing context), little mutable state, and no use of class names to specify types... I'm sure that many problems go away in this setting, and there are still advantages to using objects (inheritance, etc.) but isn't this a somewhat degraded version of the object paradigm ? > Instead of "connecting" objects > to other objects, I "connect" an objects to "actions" (functions), > which may be closures that include other objects. The typical example > which has already been given is the observer-pattern, which I use > as follows: > > class ['a] observer = > object(self) > val mutable actions = [] > method register action = > actions <- action :: actions > method notify (arg : 'a) = > List.iter (fun f -> f arg) actions > end;; > > No class for subject needed. Many of the objects I use in the GUI layer > just inherit from observer, and it's also handy if the action you want > doesn't refer to an explicit object in the OCaml layer (because the > state is kept in the external GUI layer) > [...] > > Much more annoying is that one also has to give types to arguments in > methods that are unused (they are present make them compatible with > another class, which uses them; which is where I think mutually recursive classes would be usefull, if their typing was easier. > or they are required by the GUI > layer), and that OCaml has now way to seperate method/function > declaration and type declaration (unless one uses a mli file, which is > again inconvenient because it splits information that belongs together > into two complete different places). I'd really appreciate it if one > could just mix "val" type declcarations with "let" or "method" code > declarations. > I don't understand what you want here. > >> 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. >> > > Not sure what exactly you mean here. Could you give an example? > I will try to state at an abstract level what I would like to do : - define parametric virtual classes A and B so that every A has a Bs (one or many...) and vice-versa. - possibly extend A and B to A' and B' respectively, so that every A' has B's (and not just Bs), etc. - subtyping: possibly extend B to B1 and B2 so that their objects have As, but those As still have Bs, so that I can associate the same A to objects of class B, B1 or B2. - and the ultimate goal combining all that: define A and B as above, other virtual classes C and D in a similar way and E and F too, and define concrete classes X Y Z1 Z2 just by saying that X extends A, Y will play the role of B in the first two classes and the role of C in the last two ones, and Z1 Z2 extends D (both) and E and F (respectively). It happens that some of the types that were left parametric (respectively methods defined as virtual) in B are made concrete in C, (and so on), so I obtain my final concrete classes. Finally, I want the typing to be done step by step, so that for example the incompatibilities that exist already between A and B are detected independently of the rest. I understand that what I'm asking for is a lot. The subtyping is especially problematic, and I begin to wonder if it's not related to the famous cases of inheritance that do not imply subtyping... For now, I found many introductions on ocaml objects using and how to actually use them (Ocaml manual, Didier Remy's course, the "Developing applications with Objective Caml" book, as suggested by Julien Moutinho, and also Philippe Narbel's book) but none of them went that far. Tiphaine Turpin