caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Nuutti Kotivuori <naked+caml@naked.iki.fi>
To: caml-list@inria.fr
Subject: [Caml-list] Object-oriented access bottleneck
Date: Sun, 07 Dec 2003 04:39:12 +0200	[thread overview]
Message-ID: <871xrhe4hb.fsf@iki.fi> (raw)

This message identical to the post I made to comp.lang.ml a while back
- but I think it will have a better audience over here, now that I
decided to join the list.

---

Lately I've been having a bit of a dilemma caused by a bottleneck from
object-oriented access in Ocaml. The problem derives from the
implementation of method calls through lazy binding.

Compiled languages which offer an object oriented system usually
provide a way for methods to short-circuit the lazy binding (or
virtual function table) system. In C++, non-virtual functions do this,
in Java, declaring a method final gives the compiler a hint about
this. In this case, the compiler can inline the method into the
caller.

Ocaml doesn't seem to be provide such a way. Upon closer inspection it
is obvious how this is so - if we allow subtyping by coercion, we have
no idea of the underlying implementation of the object given to the
function - where as when inheritance relationships are traditionally
forced in languages, we know that the implementation is composed of
the class atleast.

So, the obvious solution is to write the functions that do not need
the lazy binding outside the class itself, as normal functions. But
that doesn't help either - because there's no way to access data in
the object without going through a lazy binding call again.

What this all amounts to is that you cannot store data inside classes
at all, if some parts of it might require performance critical
work. The problem can be lessened by placing the data in a record,
which is only referenced from the object and passed around - or
something similar - but that adds complexity into the whole thing.

And theoretically if you absolutely *know* what type your object is
and that it isn't subtyped, you could use the direct field accesses in
Obj, but that amounts to major hackery already.

So - I am asking if I'm correct in my deductions here, or if I missed
some important point. Or if there's an alternative way to circumvent
this restriction.

To summarize - is there any way to have some function (or method or
whatever) that is able to access object member data, without the
overhead of a lazy binding function call? Preferably ofcourse such a
function should be eligible to be inlined.

Thanks in advance,
-- Naked

-------------------
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


             reply	other threads:[~2003-12-07  2:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-07  2:39 Nuutti Kotivuori [this message]
2003-12-07  2:59 ` Nicolas Cannasse
2003-12-07 11:22   ` Benjamin Geer
2003-12-07 14:12     ` Nicolas Cannasse
2003-12-07 18:04   ` Nuutti Kotivuori
2003-12-07 10:27 ` Jacques Garrigue
2003-12-07 19:46   ` Nuutti Kotivuori
2003-12-08  1:07     ` Jacques Garrigue
2003-12-08 15:08       ` Nuutti Kotivuori
2003-12-08 15:42         ` Richard Jones
2003-12-09  0:26           ` Nicolas Cannasse
2003-12-09 12:10             ` Nuutti Kotivuori
2003-12-09 13:17               ` Olivier Andrieu
2003-12-09 13:53                 ` Nuutti Kotivuori
2003-12-08 17:51       ` Brian Hurt
2003-12-08 18:19         ` brogoff
2003-12-08 20:09           ` Brian Hurt
2003-12-08 19:02         ` Xavier Leroy
2003-12-08 21:37           ` Brian Hurt
2003-12-08 21:06             ` Nuutti Kotivuori
2003-12-08 22:30             ` malc
2003-12-07 18:23 ` Brian Hurt
2003-12-07 18:14   ` Nuutti Kotivuori
2003-12-07 19:30     ` Brian Hurt
2003-12-07 23:50       ` Abdulaziz Ghuloum
2003-12-08 17:29         ` Brian Hurt
2003-12-08 18:48           ` Nuutti Kotivuori
2003-12-08 10:17       ` Nuutti Kotivuori
2003-12-08 19:51       ` 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=871xrhe4hb.fsf@iki.fi \
    --to=naked+caml@naked.iki.fi \
    --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;
as well as URLs for NNTP newsgroup(s).