[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-09-21 (22:22) |
From: | Brian Hurt <bhurt@s...> |
Subject: | Re: [Caml-list] Re: OCAML Downcasting? |
On Tue, 21 Sep 2004, Michael Vanier wrote: > Um, no, they didn't. In fact, it's a completely different mechanism. The > compiler erases the generic information so that the JVM sees only old-style > java classes without parameterization and adds casts where needed. OK, > this wasn't the greatest example in the world, because it relies massively > on RTTI. OK. I'm not up on what precisely Java is doing here. I note that they're also adding autoboxing/unboxing. > I don't agree. For instance, try implementing the equivalent of > multimethods without some kind of downcast. Of course, if a language > supported multimethods from the get-go it would be even nicer, but very few > languages do. Now, if you're going to argue that wanting multimethods at > all is a sign that you haven't thought through a problem carefully enough, > we'll just have to agree to disagree. I'm always suspicious of arguments > that start off with "you really don't want to do that", because I can't say > with any certainty what I will want to do or need to do 100% of the time. Multimethods should use variant (tagged) types, not objects and downcasting. For example, consider the case where I want to deal with a number, that could be an integer, a floating point number, or a complex (x + yi format) number. I'd implement it like: type number_t = | Int of int | Float of float | Complex of float * float ;; let add a b = match a, b with | Int(x), Int(y) -> Int(x + y) | Int(x), Float(y) | Float(y), Int(x) -> Float((float_of_int x) +. y) | Float(x), Float(y) -> Float(x +. y) | Int(x), Complex(yr, yi) | Complex(yr, yi), Float(x) -> Complex(((float_of_int x) +. yr), yi) | Float(x), Complex(yr, yi) | Complex(yr, yi), Float(x) -> Complex(x +. yr, yi) | Complex(xr, xi), Complex(yr, yi) -> Complex(xr +. yr, xi +. yi) ;; This is what I meant by not everything in Ocaml needs to be objects. Note that there is an advantage to how Ocaml does it- if you add a new tag to number_t, Ocaml will warn you in all the places you need to update to handle the new tag. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- 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