English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Marshalling objects (was: French interactive fiction, anyone ?)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-06-20 (07:42)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] Marshalling objects (was: French interactive fiction, anyone ?)
> > 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

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