[
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: | -- (:) |
| 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