chewy@apple.com (Paul Snively) (10/26/89)
In article <4671be53.20b6d@apollo.HP.COM> vinoski@apollo.HP.COM (Stephen Vinoski) writes: > Some time ago a discussion arose in comp.lang.c++ about reading objects in > from, say, a disk file. There were several answers, but none that seemed all > that great, so I hope to start a discussion of the subject here. Good! The discussion that you're trying to start essentially revolves around what are usually called "persistent objects." Persistent Objects are almost as hard to define (let alone implement) as Object-Oriented Programming is. When I think of a persistent object, I think of an object that can be stored on disk (that includes both instance variables AND methods, folks) and, if it's the first object of its class to be so stored, the appropriate class information will be stored as well (out of necessity). Persistent objects should also be able to be read back in from disk, of course. This isn't by any means a trivial set of requirements. First of all, saving methods can be anywhere from tricky to impossible. As if that weren't bad enough, what happens if you save some object (and its associated class structure), and then try to read it back into a running system where the class structure is perhaps superficially the same (e.g. the class has the same name) but differs semantically--that is, it has new class/instance variables or new/different methods? (Picture a poor programmer running into the night, screaming...) Ok, so these are some of the more obvious challenges. I'd recommend looking at lots of OOPSLA proceedings to get some idea as to where to look next. I'd also recommend reading up on distributed object systems. By the way, C++ is one of the harder languages to do persistence in, in my opinion (compared to, say, Smalltalk or Common Lisp with CLOS). __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
ssmith@joplin.mpr.ca (Shaun Smith) (10/28/89)
Since a discussion of persistent objects has sprung up I thought I'd bring up the REKURSIV chip set (VME board/computer) again. I had previously posted to comp.lang.smalltalk and comp.arch to ask whether anyone had any experience with the REKURSIV. Well, now that we have comp.object, which is probably the best place to ask that question, I'll ask it again. Would those having experience with REKURSIV like to tell us about what it's like to have a machine built from the ground up to support object-oriented programming? (the REKURSIV design is itself object-oriented, the memory manager and the cpu communicate via "messages" and memory is composed of objects, not blocks of bytes). Having said that, let me know explain what this has to do with persistent objects. The REKURSIV has _NO_ concept of temporary vs. permanent storage. That is, the concept of files does not exist. David Harland (primary architect) argues in his book that computer users should not have to deal with the problem of converting an arbitrary object into a byte stream that can be placed on permanent storage. REKURSIV's approach is to swap out objects that are not in use and keep in memory objects that are. It does not swap pages, but rather swaps individual object. The root of Harland's argument is that users should not have to think in terms of different types of storage at all. "Storage" should be seen as "Storage" and things (programs, databases, objects) should persist until disposed of. The way in which they persist should not have to be an issue for the user, they just persist. In this way, all objects are persistent. They just hang around on disk until you need them or destroy them. (This does not mean that there isn't garbage collection). This is not exactly a general solution, but it is interesting. Shaun Shaun M. Smith | ssmith@joplin.mpr.ca Microtel Pacific Research | joplin.mpr.ca!ssmith@uunet.uu.net 8999 Nelson Way, Burnaby, BC | ssmith%joplin.mpr.ca@relay.ubc.ca Canada, V5A 4B5, (604) 293-5345 | ...!ubc-vision!joplinmpr.ca!ssmith
davidm@uunet.UU.NET (David S. Masterson) (10/31/89)
In article <1852@eric.mpr.ca> ssmith@joplin.mpr.ca (Shaun Smith) writes:
Since a discussion of persistent objects has sprung up I thought I'd bring
up the REKURSIV chip set (VME board/computer) again.
Having only seen REKURSIV mentioned in the above message, it does sound
interesting, but sounds like it is too object-oriented (if that makes sense).
The hard part of today's object-orientation is how it will interface to the
non-object-oriented world. REKURSIV seems to make the assumption that
everyone dealing with persistent information is object-oriented.
--
===================================================================
David Masterson Consilium, Inc.
uunet!cimshop!davidm Mt. View, CA 94043
===================================================================
"Nobody here but us chickens..."