From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA09685; Tue, 22 Oct 2002 10:40:13 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA09586 for ; Tue, 22 Oct 2002 10:40:12 +0200 (MET DST) Received: from morgon.inria.fr (morgon.inria.fr [128.93.8.33]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g9M8eA525177; Tue, 22 Oct 2002 10:40:10 +0200 (MET DST) Received: (from remy@localhost) by morgon.inria.fr (8.11.6/8.11.6) id g9M8gem01697; Tue, 22 Oct 2002 10:42:40 +0200 Date: Tue, 22 Oct 2002 10:42:40 +0200 From: Didier Remy To: james woodyatt Cc: The Trade Subject: Re: [Caml-list] functional objects Message-ID: <20021022104240.A1694@morgon.inria.fr> Reply-To: Didier.Remy@inria.fr References: <20021021085502.A9551@morgon.inria.fr> <9C142CDC-E524-11D6-8FFC-000393BA7EBA@wetware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <9C142CDC-E524-11D6-8FFC-000393BA7EBA@wetware.com>; from jhw@wetware.com on Mon, Oct 21, 2002 at 11:40:45AM -0700 Organization: INRIA, BP 105, F-78153 Le Chesnay Cedex Phone: (33) 1 3963 5317 -- Sec: (33) 1 3963 5207 -- Fax: (33) 1 3963 5193 Web: http://cristal.inria.fr/~remy Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > I mistakenly assumed, since the documentation does not explicitly say > that the inherit clause defines a constructor method named after the > superclass, that your examples would not compile. Surprisingly, they > actually do in ocaml-3.06. I do not see how you inferred that they should not compiled form the observation that: > the documentation not explicitly say the inherit clause defines a > constructor method named after the superclass No, it does not say so and this is not true: the inherit clause (1) [behaves as if one] copies the code from the parent class (2) can be aliased to access methods of the superclass. But the inherit clause does not define a constructor method. In the examples I gave, the constructor was always explicitly defined. > I have a suspicion, though, that the implementation makes a lot of > temporary copies in this process. Is that so? Yes, it does indeed. But do you really mind? At least not in these toy examples. Unless you are using this construction in a kind of systematic way, and have long chain of inheritance, adding fields one-by-one, I am not sure that one extra copies will create a significant lost in performance. Anyway, an alternative solution is to use the class constructor (of the class you are defining) to build a new object from scratch. However, the definition must be split in two definitions because class definitions are not recursive. (* more general class *) class bar_ constr x y = object (self) inherit foo x (* allow non zero argument to foo *) val y: int = y method g (a: int) (b:int) : bar = constr a b end;; (* close the recursion and specialize x to 0 *) class bar y = bar_ (let rec c x y = new bar_ c x y in c) 0 y;; The two solutions are quite different: here (solution 2), a call to g creates a fresh object of class "bar" from scratch (running the class initializers if any) while in the previous solution it would only override (functional update) an existing object. The two solutions differ with respect to inheritance. In a subclass gnu of g, method g will have type gnu with solution 1 but will still have type bar with solution 2. There is no better solution, it just depends on the context. Didier Rémy ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners