From: Christian Stork <caml-list@cstork.org>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Execution time of class versus record
Date: Wed, 27 Jun 2007 18:13:11 -0700 [thread overview]
Message-ID: <20070628011311.GA23556@stirner.roentgeninstitut.de> (raw)
In-Reply-To: <200706251307.16487.jon@ffconsultancy.com>
On Mon, Jun 25, 2007 at 01:07:16PM +0100, Jon Harrop wrote:
...
> I was referring to virtual function dispatch and not the explicit invocation
> of a particular member.
>
> Consider this example:
>
> module A = struct
> let foo = object method f n = n+1 end
> end;;
> module B = struct
> let bar = object method f n = n+2 end
> end;;
>
> let apply o = o#f;;
>
> apply A.foo 0;;
> apply B.bar 0;;
>
> If modules imposed separate namespaces then the objects in the modules A and B
> could not be related, so you could not use them for dispatch in this way
> (probably a very common use of objects as well).
Actually, treating methods much like types wrt module namespaces is a
very sensible idea. Without going into further detail of the syntax, in
the above example, module A might declare the method A.f and if module B
intends to implement a method with same semantics as A.f it could be
written as
module B = struct
let bar = object method A.f n = n+2 end
end;;
and
let apply o = o#A.f
would work just the same. This scheme avoids unintended name clashes,
increases modularity, and, I think, it could result in a more efficient
implementation.
Unfortunately, I'd expect that programmers would react very adversly to
this unexpected additional notational burden. So there would be a need
to alleviate that burden somehow.
In the literature the above idea is sometimes called "stand-alone
messages". See Peter Froehlich's work on Lagoona[1] for more
information.
-Chris
[1]: Peter H. Froehlich, Andreas Gal, and Michael Franz. Supporting
Software Composition at the Programming-Language Level. Science of
Computer Programming, Special Issue on New Software Composition
Concepts. Volume 56, Numbers 1-2, Pages 41-57, April 2005.
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
next prev parent reply other threads:[~2007-06-28 1:13 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
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 [this message]
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=20070628011311.GA23556@stirner.roentgeninstitut.de \
--to=caml-list@cstork.org \
--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