Browse thread
[Caml-list] does class polymorphism need to be so complicated?
[
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: | Benjamin Geer <ben@s...> |
| Subject: | Re: [Caml-list] does class polymorphism need to be so complicated? |
brogoff@speakeasy.net wrote: > If you want to solve your problem, you'll need to coerce, > [...] > A solution using polymorphic methods is sketched next, These are the two options I described in my original post. Both are inconvenient. My original questions remain: Why is upcasting necessary, given that inheritance relationships are known at compile time? Could Caml be modified to correct this problem? Is any work currently being done on this? Why can't methods be polymorphic in the way that functions can be? At the very least, would it be possible to add some syntactic sugar, so we could write: method process (obj : #thing) -> (* ... *) instead of: method process : 'a . (#thing as 'a ) -> unit = fun obj -> (* ... *) It is puzzling that functions provide much better polymorphism than methods; could the Caml experts provide an explanation? Does any of the current research into Caml extensions offer a possibility of improving polymorphism for methods? 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