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 HAA28879; Mon, 16 Aug 2004 07:11:06 +0200 (MET DST) 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 HAA28972 for ; Mon, 16 Aug 2004 07:11:04 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from localhost.localdomain (220-244-134-90-vic.tpgi.com.au [220.244.134.90]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i7G5AfRM002946 for ; Mon, 16 Aug 2004 07:11:02 +0200 Received: from localhost.localdomain (blunt [127.0.0.1]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id i7G4wBke022137; Mon, 16 Aug 2004 14:58:11 +1000 Received: from blunt (jws@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) with ESMTP id i7G4wAl5022131; Mon, 16 Aug 2004 14:58:11 +1000 X-Authentication-Warning: localhost.localdomain: jws owned process doing -bs To: Caml Mailing List cc: John Prevost From: Jeff Schultz Subject: Re: [Caml-list] Restricting Method Overriding/Redefinition in Subclass Date: Mon, 16 Aug 2004 14:58:10 +1000 Message-ID: <22130.1092632290@blunt> X-Miltered: at concorde with ID 412041D1.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 overriding:01 inference:01 generics:01 verbose:01 implements:01 implements:01 typedef:01 interfaces:01 interfaces:01 trivial:01 colour:02 subclass:02 arbitrary:02 o'caml:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 1) Implementing multiple interfaces. > > In Java, things sometimes get awkward if you want to work with values > that implement multiple interfaces at once: > > class MyThingy implements Colored, HasPoint { > ... > } > > Okay, so the difficulty in this set of classes and interfaces (which > *has* actually bitten me in the wild fairly frequently) is that there > is no way to declare a variable as "any object that is of both type > Colored and type HasPoint." If we do this: > > interface ColoredHasPoint extends Colored, HasPoint { ... } > > then MyThingy is not an instance of ColoredHasPoint. It has all of > the appropriate methods, but it was not *declared* to have this type. > Therefore, it does not have the correct type. So you end up having to > write: > > void useColoredHasPoint(Object o) { > Colored c = (Colored) o; > HasPoint h = (HasPoint) o; > ... = c.getColor(); > ... = h.getPoint(); > } > > and obviously the system has now broken down. AS long as you work > with only one interface at a time, you're in fine shape. As soon as > you need more than one and have no other requirements, you're in > trouble. In O'Caml, of course, the above is trivial: > > let use_colored_has_point o = > let color = o#get_color () in > let point = o#get_point () in > ... True enough, but I think of this as more to do with the convenience provided by type inference's creation of names for types the programmer didn't write. So the type of use_colored_has_point is something like < get_color : unit -> 'a; get_point : unit -> 'b; .. > -> ... where type inference has come up with a new type that the programmer could have written, but didn't have to. One can get the same effect with Java 1.5's poor man's generics by writing void useColoredHasPoint2(T o) { Color color = o.getColor(); Point point = o.getPoint(); } so even though it's verbose, it's certainly possible. (If it also had typedef, it might not be all that bad.) Of course, just because an object has both get_color and get_point, or implements both Colored and HasPoint interfaces, doesn't mean that the colour and point returned have any specific relationship to each other, so it's not a given that mixing them on any arbitrary object makes sense. To be safe, one needs some way to check that they do go together, perhaps a ColoredPoint interface or the discipline of saying that this getPoint method is here because this object implements HasPoint, and obeys HasPoint's contract with the programmer, whatever that is, isn't always such a bad thing :-) Jeff Schultz ------------------- 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