From: Benjamin Geer <ben@socialtools.net>
To: Brian Hurt <bhurt@spnz.org>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] does class polymorphism need to be so complicated?
Date: Wed, 20 Aug 2003 17:25:57 +0100 [thread overview]
Message-ID: <3F43A115.6080201@socialtools.net> (raw)
In-Reply-To: <Pine.LNX.4.33.0308201100130.2616-100000@eagle.ancor.com>
Brian Hurt wrote:
> Instead of declaring obj to be printable, why not just declare that it has
> a function print? Like:
>
> class printer =
> object
> method print (obj: <print: unit->unit>) = obj#print ();
> end;;
>
> This removes the need for a coercion, as it gets around the need to
> upcast.
That's pretty cumbersome, because it will have to be repeated for every
method that uses an object of that type. And suppose you need the
method's argument to be an object with several methods. You could end
up writing methods like this:
class thing_processor =
object
method do_something (t : obj: <foo: int->int;
bar: unit->string;
baz: unit->bool ;
quux: unit->unit>) =
(* do something that calls all those methods *)
method do_something_else (t : obj: <foo: int->int;
bar: unit->string;
baz: unit->bool;
quux: unit->unit>) =
(* do something else that calls all those methods *)
end;;
It would seem natural to define an interface as a shorthand, and to use
it like this:
class type thing =
object
method foo : int -> int
method bar : string
method baz : bool
method quux : unit
end;;
class thing_processor =
object
method do_something (t : #thing) =
(* do something that calls all those methods *)
method do_something_else (t : #thing) =
(* do something that calls all those methods *)
end;;
But alas, this is not valid in Caml.
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
next prev parent reply other threads:[~2003-08-20 16:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-20 15:42 Benjamin Geer
2003-08-20 16:05 ` Brian Hurt
2003-08-20 16:19 ` Richard Jones
2003-08-20 16:25 ` Benjamin Geer [this message]
2003-08-20 17:09 ` brogoff
2003-08-20 17:25 ` Jacques Carette
2003-08-20 23:34 ` Jacques Garrigue
2003-08-21 13:27 ` Jacques Carette
2003-08-20 18:19 ` Benjamin Geer
2003-08-20 20:39 ` brogoff
2003-08-20 21:04 ` Benjamin Geer
2003-08-21 0:28 ` Jacques Garrigue
2003-08-21 8:17 ` Benjamin Geer
2003-08-21 8:58 ` Jacques Garrigue
2003-08-21 9:38 ` Benjamin Geer
2003-08-21 11:44 ` Remi Vanicat
2003-08-21 13:11 ` Richard Jones
2003-08-21 16:41 ` Remi Vanicat
2003-08-21 18:04 ` brogoff
2003-08-21 20:20 ` Benjamin Geer
2003-08-21 23:35 ` Benjamin Geer
2003-08-22 3:59 ` Jacques Garrigue
2003-08-22 7:12 ` Benjamin Geer
2003-08-21 13:38 ` Benjamin Geer
2003-08-21 0:58 ` brogoff
2003-08-20 23:40 ` Benjamin Geer
2003-08-21 1:29 ` Jacques Garrigue
2003-08-21 9:19 ` Benjamin Geer
2003-08-21 18:44 ` Chris Clearwater
2003-08-20 20:43 ` Issac Trotts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F43A115.6080201@socialtools.net \
--to=ben@socialtools.net \
--cc=bhurt@spnz.org \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox