Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] does class polymorphism need to be so complicated?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-08-20 (21:08)
From: Benjamin Geer <ben@s...>
Subject: Re: [Caml-list] does class polymorphism need to be so complicated? 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?


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: