Xref: utzoo comp.lang.c++:5537 comp.object:421 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++,comp.object Subject: Re: Shippable C++ Objects (RFC) Message-ID: Date: 17 Nov 89 19:14:18 GMT References: <31.UUL1.3#5109@pantor.UUCP> Sender: davidm@cimshop.UUCP Organization: Consilium Inc., Mountain View, California. Lines: 29 In-reply-to: richard@pantor.UUCP's message of 16 Nov 89 13:43:31 GMT In article <31.UUL1.3#5109@pantor.UUCP> richard@pantor.UUCP (Richard Sargent) writes: [edited quote follows] > 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! ... The real trick will be to eliminate the need for [...] a switch! If anyone figures this out for C++, I'm waiting with bated breath That was why I suggested the Event interface (a la X windows) as the method for passing things to new processes. Each Event would be registered with an appropriate callback (which might be wrappable as an object). Therefore, whenever an application takes on new functionality, it acquires a new callback which would be registered with the event processor in the usual fashion. So, a program capable of accepting an object of (say) XClass would have already registered the construction callback XClassConstruct with its Event processing mechanism. -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"