From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA00663; Thu, 20 Jun 2002 09:42:22 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA00627 for ; Thu, 20 Jun 2002 09:42:21 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g5K7fl506933; Thu, 20 Jun 2002 09:41:47 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA00562; Thu, 20 Jun 2002 09:41:47 +0200 (MET DST) Date: Thu, 20 Jun 2002 09:41:47 +0200 From: Xavier Leroy To: Jacques Garrigue Cc: berke@altern.org, caml-list@inria.fr Subject: Re: [Caml-list] Marshalling objects (was: French interactive fiction, anyone ?) Message-ID: <20020620094147.A77@pauillac.inria.fr> References: <20020617233800.C16032@gogol.zorgol> <20020618065723.GJ4232@alan-schm1p> <20020619175654.A14466@gogol.zorgol> <20020620140857P.garrigue@kurims.kyoto-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i 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 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > 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