Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!cam-cl!scc From: scc@cl.cam.ac.uk (Stephen Crawley) Newsgroups: comp.object Subject: Re: Re: Shippable C++ Objects (RFC) Message-ID: <1678@gannet.cl.cam.ac.uk> Date: 29 Nov 89 18:09:29 GMT References: <8410001@hp-ses.SDE.HP.COM> Sender: news@cl.cam.ac.uk Organization: U of Cambridge Comp Lab, UK Lines: 32 > kipp@warp.sgi.com (Kipp Hickman) writes: > > To eliminate the ``switch'' implied by the object reconstruction > > mechanism, all you need is a dictionary. The key is the tag which > > identifies the object in its byte stream form (a string works nicely). > > The value is a pointer to a function to perform the reconstruction. > > This solution does indeed eliminate the switch, > but it doesn't eliminate the problem: > how does the receiving process know what to put in the dictionary? > > The dictionary has to be initialized with all interesting > classes (and their corresponding keys) before any objects can > be reconstructed. If a new class is added to the common library, > the code for the receiving process has to be updated to add > the new class to the dictionary. (not much different than adding > a new case to a switch statement) > > Is there any way for the sending process to tell the receiving > one which classes of instances are coming down the wire? How about this? Let us assume that objects have globally unique identifiers, and that the object architecture allows a program to locate an object given its id. Now make type tag passed in a serialised object the id for the object that represents its type. If the receiving end has the appropriate object reconstructor in the local dictionary, fine. If not, it can located via the respective type object and fetched into the dictionary using the normal object transmission mechanism. You only need to make sure that the local dictionary is started up with a reconstructor for type objects. -- Steve Brought to you by Super Global Mega Corp .com