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 PAA13202; Tue, 16 Jul 2002 15:59:43 +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 PAA13233 for ; Tue, 16 Jul 2002 15:59:42 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from athlon.baretta.com (r-mi214-6a44.tin.it [62.211.4.44]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g6GDxeb11809 for ; Tue, 16 Jul 2002 15:59:41 +0200 (MET DST) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id 27C9F2724F; Tue, 16 Jul 2002 16:06:45 +0200 (CEST) Message-ID: <3D342875.2000704@baretta.com> Date: Tue, 16 Jul 2002 16:06:45 +0200 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: it, en MIME-Version: 1.0 To: John Prevost , Ocaml Subject: Re: [Caml-list] Recovering masked methods (with CamlP4?) References: <3D335729.3020307@baretta.com> <20020716101520Q.garrigue@kurims.kyoto-u.ac.jp> <3D33E74C.6050307@baretta.com> <20020716095939.M27616@wanadoo.fr> <3D33FE98.6000001@baretta.com> <86u1mzu7c7.fsf@laurelin.dementia.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk John Prevost wrote: > You've simply got the wrong ordering in your inheritance. There's > absolutely no need for more functionality to support accessing "older" > methods in this case. (I'd argue there's no need in any case.) And > again, even if method m had to be different in var_b, it would be > better to use an inherited class which has the features common to b > and var_b. In this case, that class is identical to b. > > John. Not a bad idea, actually. From a conceptual standpoint it works. It did not occur to me go about coding that way because my classes come in "related packages", and given this conceptual grouping, it would sort of look funny to implement what you suggested. ... Now that you make me think of it, all I need is an intermediate class in my hierarchy, factoring all the the common functionality with the exception of two methods: let's say m and n. I'll then have a package inherit from the common ancestor and redefine m, while the other package redefines n. This intermediate layer will remove the need to call a method in a farther ancestor. Thank you for the suggestion. Alex ------------------- 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