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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 8ECB5BBCA for ; Mon, 25 Feb 2008 21:16:00 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFiwwkfVpUAUmWdsb2JhbACQXgEBAQEBBgQGCQgWgQ+ZJQ X-IronPort-AV: E=Sophos;i="4.25,403,1199660400"; d="scan'208";a="7678075" Received: from mail.gmx.net ([213.165.64.20]) by mail2-smtp-roc.national.inria.fr with SMTP; 25 Feb 2008 21:16:00 +0100 Received: (qmail invoked by alias); 25 Feb 2008 20:15:56 -0000 Received: from dialin-145-254-248-226.pools.arcor-ip.net (EHLO dialin-145-254-248-226.pools.arcor-ip.net) [145.254.248.226] by mail.gmx.net (mp055) with SMTP; 25 Feb 2008 21:15:56 +0100 X-Authenticated: #11134691 X-Provags-ID: V01U2FsdGVkX1/8OIt1Cz/8SJaERdWk1wiaZU7br1J2hYvOyu4LnN po2dvNeIGEQVB6 Received: from dirk by feanor.private-host.de with local (masqmail 0.2.20) id 1JTjel-1Pj-00 for ; Mon, 25 Feb 2008 21:10:35 +0100 Date: Mon, 25 Feb 2008 21:10:35 +0100 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OO programming Message-ID: <20080225201035.GA5414@feanor> References: <47BD44FE.3050001@irisa.fr> <20080224163308.GA3459@feanor> <47C288FD.8070602@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47C288FD.8070602@free.fr> User-Agent: Mutt/1.5.6+20040523i From: Dirk Thierbach X-Y-GMX-Trusted: 0 X-Spam: no; 0.00; 0100,:01 0100,:01 recursive:01 mutable:01 computations:01 computations:01 recursive:01 val:01 subtype:01 parametric:01 vice-versa:01 subtyping:01 parametric:01 inference:01 typings:01 On Mon, Feb 25, 2008 at 10:23:09AM +0100, Tiphaine.Turpin wrote: > Dirk Thierbach a écrit : > >On Thu, Feb 21, 2008 at 10:31:42AM +0100, Tiphaine Turpin wrote: > 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.) Let me repeat: The main advantage of OO is that you can group related state together, and that you can "push" changes (events, secondary changes caused by events, whatever) onto this network of state. While the functional way (especially with lazy computations) is to "pull" a result from a network of computations. > but isn't this a somewhat degraded version of the object paradigm ? Well, people can't seem to agree what exactly the "object paradigm" actually is in the first place :-). Personally, I don't care. I want clean, flexible, decoupled code. I am not interested in doing something just because eomeone tells me, possible mistakenly, that I have to follow "the" paradigm. >> 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. 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'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. See Edgar's response. But that was only just a side-remark. >>> 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. If you manage to find a simple type system for that, preferably with type inference and principal typings, I'd like to see it :-) > 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. :-) You can fight the system, and try to make everything difficult because you think "it ought to be this way", or you can go the easy route. Your choice. I can only tell you what I found that works for me. - Dirk