From: Ted Kremenek <kremenek@cs.stanford.edu>
To: skaller <skaller@users.sourceforge.net>
Cc: david.baelde@ens-lyon.org, Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] Class/prototype-based OO
Date: Mon, 28 Aug 2006 20:11:03 -0700 [thread overview]
Message-ID: <E1E927D0-2415-4F81-9F1E-18DAC01A1BC1@cs.stanford.edu> (raw)
In-Reply-To: <1156505490.20759.354.camel@rosella.wigram>
On Aug 25, 2006, at 4:31 AM, skaller wrote:
> Thus, from a software engineering viewpoint, nominal typing
> is not a viable option .. which is one reason programming
> in Java or C++ using OO sucks.
>
> In Ocaml, it works much better because you can actually
> write algorithms which work with many different types,
> provided only they support the 'right methods'.
While the structural typing in Ocaml is wonderful (I really love it),
there are missing features of the OO system in OCaml that can be
particularly bothersome, and are worth considering when comparing the
OO features of Ocaml with other languages (including those that use
nominal typing).
For example, from what I can tell it appears that Ocaml lacks real
support for "downcasts" in the language, which require run-time type
information (RTTI) and run-time checks. In the context of structural
typing, I am talking about "casting" an object with a type with a
given set of method signatures to another type with an extended set
of method signatures. Whether or not you agree downcasts are a good
thing, it is one thing to take into account when comparing the OO
features of different languages (and this is a feature that both C++
and Java have that OCaml does not). In general, I don't believe the
OO system in Ocaml supports any kind of RTTI, which enables features
such as downcasts and reflection. All of the type checking of
objects in OCaml is static, which is very nice but often insufficient.
Actually, if I am wrong about this I would be very happy if someone
out there can point this out. Certainly one can implement downcasts
using Obj.magic and some hand-crafted RTTI, but that is obviously not
a desired solution.
next prev parent reply other threads:[~2006-08-29 3:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-25 7:51 David Baelde
2006-08-25 11:31 ` [Caml-list] " skaller
2006-08-29 3:11 ` Ted Kremenek [this message]
2006-08-29 5:53 ` skaller
2006-08-30 23:57 ` brogoff
2006-08-29 12:03 ` Gerd Stolpmann
2006-08-29 17:56 ` Ted Kremenek
2006-08-29 18:13 ` Ted Kremenek
2006-08-31 1:11 ` Jacques Garrigue
2006-08-31 5:18 ` skaller
2006-08-31 6:36 ` Jacques Garrigue
2006-08-31 7:15 ` skaller
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=E1E927D0-2415-4F81-9F1E-18DAC01A1BC1@cs.stanford.edu \
--to=kremenek@cs.stanford.edu \
--cc=caml-list@inria.fr \
--cc=david.baelde@ens-lyon.org \
--cc=skaller@users.sourceforge.net \
/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