From: Benjamin Geer <ben@socialtools.net>
To: brogoff@speakeasy.net
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] does class polymorphism need to be so complicated?
Date: Thu, 21 Aug 2003 00:40:50 +0100 [thread overview]
Message-ID: <3F440702.8040704@socialtools.net> (raw)
In-Reply-To: <Pine.LNX.4.44.0308201312120.7047-100000@grace.speakeasy.net>
brogoff@speakeasy.net wrote:
> Yes, OCaml doesn't have implicit subtyping. [...]
> If you want to solve your problem, you'll need to coerce, and you
> can solve it fairly simply by replacing the troublesome line below with one of
> the following
>
> tp#process (et :> fbbq) ;;
>
> or
>
> let proc o = (new thing_processor)#process (o :> fbbq);;
> proc et;;
I've thought some more about this idea of wrapper functions, and
actually, it doesn't seem simple at all.
In an object-oriented program, *all* methods are potentially
polymorphic; this is what makes object orientation useful. It means
that you can always pass, to a method in class C, an instance of a class
that didn't exist yet when C was written. A library's author therefore
doesn't need to anticipate all the classes that will ever use the library.
If you used wrapper functions to do coercions, you would need a wrapper
function for every method in the program. This would be extremely
cumbersome and ugly, and hardly object-oriented.
Doing coercions at the call site is equally cumbersome, and you lose the
ability to change the method so that it accepts a less derived class.
It seems to me that the idea of interfaces (class types) is quite
powerful, and would be a good solution, if only the syntax for using
them in method definitions were not so complicated.
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 23:44 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
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 [this message]
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=3F440702.8040704@socialtools.net \
--to=ben@socialtools.net \
--cc=brogoff@speakeasy.net \
--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