From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Execution time of class versus record
Date: Mon, 25 Jun 2007 04:25:28 +0100 [thread overview]
Message-ID: <200706250425.28516.jon@ffconsultancy.com> (raw)
In-Reply-To: <467EBD16.7060303@lix.polytechnique.fr>
On Sunday 24 June 2007 19:51:02 Arnaud Spiwack wrote:
> ...btw object coercion should never cost anything
> since they are merely type level tools...
Even in statically typed systems you might well want to shift work to run-time
(e.g. specialization of all-float records/arrays) so I see no reason to
expect coercion to be free.
> At runtime, I can't see anything to preven objects to be exactly records
> (with a bit of care taken during compilation for method names).
How can the current representation of records handle virtual method dispatch?
> John
> Skaller's answer is not really convincing either, since the type of a
> value does not change the size of the value, having the same name
> associated to different types does not seem to me a good motivation.
I think this choice makes OCaml's object system more orthogonal to the rest of
the language.
> Another lead is maybe something due to module compilation, the
> earlier idea might imply that each module has it's own namespace (it's
> the case for almost everything in OCaml, except, if I'm not mistaking,
> method names
and polymorphic variants.
> If it is the motivation for having a runtime
> representation of objects different to that of records, the question
> that raises nex is: what is the motivation for not having
> module-specific namespaces for method names?
If I have two modules containing two classes and I want them to be related,
how can you implement that with structurally-subtyped OO if method names are
local to modules?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e
next prev parent reply other threads:[~2007-06-25 3:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-24 15:14 tmp123
2007-06-24 15:29 ` [Caml-list] " Jon Harrop
2007-06-24 15:48 ` Till Varoquaux
2007-06-24 16:06 ` Arnaud Spiwack
2007-06-24 18:18 ` skaller
2007-06-24 18:29 ` Gerd Stolpmann
2007-06-24 18:51 ` Arnaud Spiwack
2007-06-24 19:11 ` Chris King
2007-06-25 3:25 ` Jon Harrop [this message]
2007-06-25 11:16 ` Arnaud Spiwack
2007-06-25 12:07 ` Jon Harrop
2007-06-25 23:59 ` Jonathan Bryant
2007-06-26 0:15 ` Chris King
2007-06-26 6:53 ` Loup Vaillant
2007-06-26 7:02 ` Jon Harrop
2007-06-26 17:07 ` Loup Vaillant
2007-06-28 1:13 ` Christian Stork
2007-06-26 13:35 ` Sam Steingold
2007-06-26 16:29 ` [Caml-list] " Quôc Peyrot
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=200706250425.28516.jon@ffconsultancy.com \
--to=jon@ffconsultancy.com \
--cc=caml-list@yquem.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