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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 7B605BBCA for ; Mon, 25 Feb 2008 22:53:55 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.25,403,1199660400"; d="scan'208";a="9568914" Received: from 109.215.100-84.rev.gaoland.net (HELO [192.168.0.3]) ([84.100.215.109]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Feb 2008 22:53:54 +0100 Message-ID: <47C337FD.9030001@free.fr> Date: Mon, 25 Feb 2008 22:49:49 +0100 From: "Tiphaine.Turpin" User-Agent: Thunderbird 1.5.0.10 (X11/20070303) MIME-Version: 1.0 To: Dirk Thierbach Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OO programming References: <47BD44FE.3050001@irisa.fr> <20080224163308.GA3459@feanor> <47C288FD.8070602@free.fr> <20080225201035.GA5414@feanor> In-Reply-To: <20080225201035.GA5414@feanor> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam: no; 0.00; ocaml:01 extensively:01 recursive:01 ocaml:01 recursive:01 parametric:01 vice-versa:01 subtyping:01 parametric:01 inference:01 typings:01 didier:01 remy's:01 height:98 abstract:01 Dirk Thierbach a écrit : > I am not interested in doing something > just because eomeone tells me, possible mistakenly, that I have to > follow "the" paradigm. > I won't blame you for that. I'm not either :-). The few (2-3) programs of "not-toy" size that I did using objects (either in Java or in Ocaml) both extensively used many linked objects implementing lots of methods in a mutually recursive way, so I consider this an crucial features of objects. And really, I code things the way I think I'm able to do them the best (I have the chance that my programs only need to look nice to me): I do what I can. I choose functional or imperative style according to my best understanding of the domain, or objects (in Ocaml, I consider objects only if I think that I cannot achieve my goals in a satisfactory way with functions). > >>> 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. >> > > Mutual recursive classes won't solve this problem at all. Yes it does, I think (wether it's a good way of solving it is debatable). If you declare the classes generating events together with classes that handle them, and if it appears (in the declaration, which is where fields are usefull) that the method used in the generating objects will be invoked on the handler objects, then the types of the two methods will need to be compatible. Of course, in your example, you would probably want to use either a class type for handler objects, or have them inherit from a virtual handler class that declare the type of the method once and for all. My point is that using in one of the classes the type associated with the other class for one of its fields (and invoking methods on that fields) puts the necessary constraints to free you from many declarations (mutual recursive classes are actually only needed if you want links in both directions, which is not necessarily the case of your example, I agree). > Maybe an > example helps: In a GUI, one can get various sorts of events, say, > a "resize" event. If the method connected to that event is only > interested in the new width and not in the height, so it doesn't > use this value at all, you have to declare the type. No other class > involved at all. > >> 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. >> > > If you manage to find a simple type system for that, preferably with > type inference and principal typings, I'd like to see it :-) > I wish I could do that in Ocaml... >> 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. >> > > So maybe there's a reason they are doing it differently. :-) They aren't doing differently. They're just not treating an exhaustive list of the software architecture problems that people may encouter (or, pose to themselve). Which does not scandalize me in itself ;-). Tiphaine Turpin