caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <xavier.leroy@inria.fr>
To: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
Cc: berke@altern.org, caml-list@inria.fr
Subject: Re: [Caml-list] Marshalling objects (was: French interactive fiction, anyone ?)
Date: Thu, 20 Jun 2002 09:41:47 +0200	[thread overview]
Message-ID: <20020620094147.A77@pauillac.inria.fr> (raw)
In-Reply-To: <20020620140857P.garrigue@kurims.kyoto-u.ac.jp>; from garrigue@kurims.kyoto-u.ac.jp on Thu, Jun 20, 2002 at 02:08:57PM +0900

> > since Caml can save closures under
> > the same constraints, the reason why objects can't be saved must be
> > something else.
> 
> Actually I cannot remember any such reason.
> I actually tried, just commenting out the Object_tag case in
> byterun/extern.c, and it works!

I'm always suspicious about "it works!" claims :-)

IIRC, one of the potential issues here is that methods are numbered at
program start-up time, via the Oo.new_method support function.  The
numbering of methods, then, determines the layout of vtables.  With
your solution, you're saving and reloading the vtable of the object as
a normal data structure.  This is correct only if the program that
saves the object and the program that reads it assign the same numbers
to methods.  But it isn't entirely obvious that two runs of the same
executable code on different data will assign the same numbers to
methods.  (Think e.g. of a conditionalized "let module" containing a
class declaration.)  It seems to work in the current compiler, but I
feel this scheme of dynamic allocation of method identifiers is quite
fragile.

Another potential issue is the un-sharing of vtables: in the present
system, all instances of a class share a common vtable; this is no
longer true with your marshaling/unmarshaling scheme.  Again, this
doesn't seem to break anything, but I'd like to be certain that
pointer equality on vtables is nowhere used.

> There's a single glitch: as it just handles objects as normal data,
> oid's are not updated. This means that equality on objects (which is
> oid based) will be incorrect.

This issue could be addressed by special-casing Object_tag in input_value,
and making the OID counter available from C.

> On the other hand, objects are not just closures, and it would be nice
> to be able to serialize their data in a code-independent way. Not so
> unreasonable: class names are unique.

Methinks you're confusing Caml with Java :-)  What kind of unique
class names do you have in mind?

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


  parent reply	other threads:[~2002-06-20  7:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-17 21:38 Berke Durak
2002-06-18  6:57 ` Alan Schmitt
2002-06-19 15:56   ` Berke Durak
2002-06-20  5:08     ` Jacques Garrigue
2002-06-20  7:16       ` Christopher Quinn
2002-06-20  7:41       ` Xavier Leroy [this message]
2002-06-20 14:39         ` Jacques Garrigue
2002-06-21  9:09           ` Jacques Garrigue

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=20020620094147.A77@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=berke@altern.org \
    --cc=caml-list@inria.fr \
    --cc=garrigue@kurims.kyoto-u.ac.jp \
    /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).