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 LAA15068; Thu, 21 Aug 2003 11:23:39 +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 LAA10629 for ; Thu, 21 Aug 2003 11:23:38 +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 h7L9Nbf19430 for ; Thu, 21 Aug 2003 11:23:37 +0200 (MET DST) Received: by rabelais.socialtools.net (Postfix, from userid 108) id C804D23311; Thu, 21 Aug 2003 10:23:36 +0100 (BST) Received: from socialtools.net (chaucer.socialtools.net [81.2.94.242]) by rabelais.socialtools.net (Postfix) with ESMTP id 60AD62330E; Thu, 21 Aug 2003 10:23:35 +0100 (BST) Message-ID: <3F448EB2.9020103@socialtools.net> Date: Thu, 21 Aug 2003 10:19:46 +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: <3F440702.8040704@socialtools.net> <20030821102946Y.garrigue@kurims.kyoto-u.ac.jp> In-Reply-To: <20030821102946Y.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 outset:99 this':99 lablgtk:01 shorter:01 coercions:01 'open:01 garrigue:01 interfaces:01 coercion:01 polymorphic:01 syntax:02 hierarchy:02 philosophy:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Jacques Garrigue wrote: > Even for object arguments, not all classes make sense when extended. The problem is that it is often difficult to know, at the outset, whether it makes sense for a class to be extended. Sometimes you start out with a concrete class, thinking 'no one will ever want to extend this', and later you realise that it should have been an interface, because there's a real need for different implementations. It's easier to change a class into an interface if all methods that use the class don't also have to change, i.e. if the syntax for using an interface is the same as the syntax for using a class. Another approach is to use interfaces for everything. But then you really need a lightweight syntax for handling interfaces in methods. > So we are back to an often fairly small number of methods (in my > experience one or two by big class, but it may depend heavily on your > design) See my last message, about writing and using libraries. > Another approach which was not described yet, and which I use in > lablgtk for instance, is to add a coercion method to classes which form > the top of a hierarchy. [...] I agree that this is a slight improvement; it's basically a shorter coercion syntax. Why did you decide to use this approach in lablgtk, instead of the other approach you suggested (using virtual methods that accept class types)? > This all depends of the number of methods taking printable as > argument. If there are only a few of them, wrapping functions or > polymorphic methods are probably a good idea. If there are lots of > them, then adding such a coercion method may make your design clearer. It's often difficult to know, at the outset, how many methods will ultimately use any given class, particularly if you're writing a library. Perhaps initially there will only be a few, and later on there will be many. Object-oriented programming should mean that you don't have to know or care. The point about clarity is interesting, though; you seem to be saying that coercions make code clearer. While this may be true, the whole philosophy of ML seems to be about giving the programmer a choice: type specifications are necessary only when there is ambiguity, and are optional elsewhere. Since there is no possible ambiguity in the case we're talking about, wouldn't you rather have the choice? This is why the approach using 'open rows' seems more appealing to me. > And if you're going to change the requirements of a method in the > middle of your development, this means that there was something wrong > in your design. Unfortunately, as hard as we may try to create the perfect design, designs always change over time. I think programming languages should try to make those changes as painless as possible. 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