Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!uw-beaver!uw-june!peterd From: peterd@cs.washington.edu (Peter C. Damron) Newsgroups: comp.lang.c++ Subject: Re: Shippable C++ Objects (RFC) Summary: language theory and address spaces Message-ID: <9854@june.cs.washington.edu> Date: 17 Nov 89 18:55:44 GMT Article-I.D.: june.9854 References: <31.UUL1.3#5109@pantor.UUCP> <1044@east.East.Sun.COM> Reply-To: peterd@june.cs.washington.edu.cs.washington.edu (Peter C. Damron) Organization: University of Washington, Computer Science, Seattle Lines: 76 Keywords: In article <1044@east.East.Sun.COM> db@helium.East.Sun.COM (David Brownell) writes: >In article <31.UUL1.3#5109@pantor.UUCP> > richard@pantor.UUCP (Richard Sargent) writes: >>> From: cimshop!davidm@uunet.UU.NET (David S. Masterson) >>> 3. Assume each class of objects has methods for filling (or constructing) >>> itself from the shippable byte array representation made in (2). ... >>Here's the nub of the problem! ... >It's also, surprise!, essentially the same idea that shows up in >networking for how to serialize and deserialize RPC arguments. >>"The object can reconstruct itself from the byte stream" requires >>that the object already exist. It still seems to me that you *have* >>to have a case statement somewhere which knows about all (interesting) >>object classes. The cases create each new type of object, probably using >>a class constructor which has a ByteStreamRepresentation argument. It seems to me that this ByteStreamRepresentation is a string language where the objects are the words or tokens of the language. The only way to parse that language in which you know the type of the object before you see it occurs if the langauge is LL(0) and you are using a top-down parser. LL(0) is not a very powerful class of languages. Given that you want to send your LL(1) or LR(1) string of objects, you could first convert these objects into LL(0) objects by adding "syntactic sugar" into the language. This amounts to adding tokens/objects that tell the type/class of the following object. This does not eliminate the "case statement" described above, but it potentially splits the case statement accross many syntactic sugar objects and it probably makes it easier to adapt to changes in the language of the byte stream. >Sort of; "object" is distinct from a data format. The process is taking >data in one format from one data store into another, and constructing a >NEW object by binding methods to the new data representation. What's >shipped is data, not data plus code, and the new methods might not >implement the class used by the message sender. The key points are needing >to use a constructor function, and needing to choose which of several >constructors to use. This is a good point. In OO systems, code is bundled with objects. If you want to maintain the object type/class accross an address boundary, then code has to get moved/referenced as well as data. >No application will be able to understand all types/classes ... they get >incrementally added to real systems over time... Good point. See above about the syntactic sugar. The point that everyone seems to be missing in this disscussion is: Why do you want to convert objects in the byte streams in the first place? Why not just move objects "as is" to another address space? Of course, this implies that you have ways to address objects in another address space, and that is another problem. Better yet, just get rid of the different address spaces. After all, partitioning objects into address spaces in an object oriented system are just an efficiency hack. The object is the address space. Hope this helps, Peter. --------------- Peter C. Damron Dept. of Computer Science, FR-35 University of Washington Seattle, WA 98195 peterd@cs.washington.edu {ucbvax,decvax,etc.}!uw-beaver!uw-june!peterd