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 LAA16883; Thu, 21 Aug 2003 11:42:02 +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 LAA29082 for ; Thu, 21 Aug 2003 11:42:00 +0200 (MET DST) Received: from rabelais.socialtools.net (rabelais.socialtools.net [81.2.94.243]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h7L9fxf21298 for ; Thu, 21 Aug 2003 11:41:59 +0200 (MET DST) Received: by rabelais.socialtools.net (Postfix, from userid 108) id 68CE923311; Thu, 21 Aug 2003 10:41:59 +0100 (BST) Received: from socialtools.net (chaucer.socialtools.net [81.2.94.242]) by rabelais.socialtools.net (Postfix) with ESMTP id 2D3802330E; Thu, 21 Aug 2003 10:41:58 +0100 (BST) Message-ID: <3F449301.8050500@socialtools.net> Date: Thu, 21 Aug 2003 10:38:09 +0100 From: Benjamin Geer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-gb, en, fr, it MIME-Version: 1.0 To: Jacques Garrigue Cc: caml-list@inria.fr Subject: Re: [Caml-list] does class polymorphism need to be so complicated? References: <3F43E250.1040903@socialtools.net> <20030821092849B.garrigue@kurims.kyoto-u.ac.jp> <3F448015.8090106@socialtools.net> <20030821175808V.garrigue@kurims.kyoto-u.ac.jp> In-Reply-To: <20030821175808V.garrigue@kurims.kyoto-u.ac.jp> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG autolearn=ham version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 jacques:01 superclass:01 downcast:01 passing:01 implements:01 ocaml:01 garrigue:01 syntax:02 subclass:02 deeper:02 unit:03 classes:03 wrote:03 obj:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Jacques Garrigue wrote: > Here there may be a deeper misunderstanding about the ocaml type > system: if a subclass does not add methods to its superclass, its type > does not change. > That is, I would expect all connections to have the same type, and as > a result there is no need for considering the more general > #connection. I think this would place an undesirable restriction on driver authors. They may want to add additional methods to their implementation of #connection, for use by other classes in the driver, even if the user will never be able to call those methods. In general, this approach allows for a complete separation between interface and implementation: the implementing class can always have more methods than the interface, if this makes the implementation more convenient to write. Alternatively, you could use a virtual base class 'connection', and always downcast the implementing class before passing it to application code. But this places an additional burden on the library author. > OK, there's also another way to do it, without inheritance. I just > tried not to be confusing. > > class type printer = object > method virtual print : #printable -> unit > end > > class my_printer () = object (self : #printer) > method print obj = ... > end > > Looks a bit strange at first, but it does the work. Is there a way to write a class that implements more than one interface? I've tried the following, but it produces a syntax error: class type virtual printer = object method virtual print : #printable -> unit end ;; class type virtual talker = object method virtual talk : #printable -> unit end ;; class my_printer_talker () = object (self : #printer; #talker) method print obj = (* ... *) method talk obj = (* ... *) end ;; Am I right in guessing that you have to use multiple inheritance to achieve this? Ben ------------------- 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