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: | brogoff@s... |
| Subject: | Re: [Caml-list] does class polymorphism need to be so complicated? |
On Wed, 20 Aug 2003, Benjamin Geer wrote:
> 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:
Sorry, I didn't read your original post, only Brian Hurt's reply to it.
Jacques Garrigue explained the reasons why it is hard to do everything you
want in OCaml, but I still think you are being a bit harsh.
First, calling the methods through functions is not the uncontested evil that
you make it out to be.
http://www.cuj.com/documents/s=8042/cuj0002meyers/
Second, I don't think that there would be a big gain in productivity by
changing the polymorphic method syntax. As JG points out, it's not too much
work to ensure that the user of the code doesn't need to use that syntax, as
long as the library author is careful, so for instance
class virtual processor =
object
method virtual process : 'a . (#thing as 'a ) -> unit
end;;
class thing_processor =
object
inherit processor
method process obj =
begin
obj#quux;
print_string (string_of_int (obj#foo 1));
print_string obj#bar;
print_string (string_of_bool obj#baz);
print_endline ""
end
end ;;
and in any realistic program the virtuals will be in some separate module.
Having had a foot in the Ada world, I appreciate this little bit of verbosity
in which the typing is all laid out. My problem is not usually the issue of
changing text, but the issue of remembering what the types of things are.
-- 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