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 QAA09463; Thu, 20 Jun 2002 16:39:34 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA09233 for ; Thu, 20 Jun 2002 16:39:33 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g5KEdQH25464; Thu, 20 Jun 2002 16:39:29 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id XAA13425; Thu, 20 Jun 2002 23:39:19 +0900 (JST) To: xavier.leroy@inria.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] Marshalling objects (was: French interactive fiction, anyone ?) In-Reply-To: <20020620094147.A77@pauillac.inria.fr> References: <20020619175654.A14466@gogol.zorgol> <20020620140857P.garrigue@kurims.kyoto-u.ac.jp> <20020620094147.A77@pauillac.inria.fr> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020620233919K.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 20 Jun 2002 23:39:19 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Great, an implementer's discussion on the Caml list! Where is Jerome ?! From: Xavier Leroy > > > 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 :-) The bang expressed an experimental truth, which can be reverted by other experiments :-) > 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. After a deeper look at -dlambda and oo.ml, this holds, but only as long as you're not using let modules. That is, public labels are correctly lifted to the toplevel, but private labels may be generated at class initialization. Since classes are toplevel structures inside modules, class initializations occur in a fixed order as long as there are no let modules. But even that is easy to fix: private labels are local to a class, and they need not be kept between runs. However public labels must not change. The current scheme has one single counter for both kinds of labels, but it should be easy to use two counters, putting public and private methods in different buckets. > 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. It's not a scheme, it's inaction... I should look more carefully, but I don't see any point in using pointer equality on vtables, except for some kind of unspecified reflection. Note that it does not guarantee type equality, as classes may be parameterized. > > 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. Yes, the only subtlety is that the counter is on the caml side, so you need a callback for that. > > 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? Since a class definition also defines a type, module semantics say that every class name is unique inside its module. From that I thought we could get the same thing as exception names: use the path. But maybe I overlooked something? Note that let modules would be a problem though. Jacques ------------------- 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