Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!emory!cambridge.apple.com!bloom-beacon!eru!luth!sunic!mcsun!ukc!newcastle.ac.uk!cabernet!graham From: graham@cabernet.newcastle.ac.uk (Graham D. Parrington) Newsgroups: comp.lang.c++ Subject: Re: Shippable C++ Objects (RFC) Message-ID: <1989Nov20.091634.6562@newcastle.ac.uk> Date: 20 Nov 89 09:16:34 GMT References: <31.UUL1.3#5109@pantor.UUCP> <4042@cadillac.CAD.MCC.COM> Sender: news@newcastle.ac.uk Organization: Computing Laboratory, University of Newcastle upon Tyne, UK, NE1 7RU Lines: 27 dld@F.GP.CS.CMU.EDU (David Detlefs) writes: >I think this is a (somewhat) false assumption. Consider a strongly >typed RPC interface. The sender must send the right type of object, >or else type-checking would fail. The receiver knows the expected >type of the RPC argument, and can use his knowledge of the type to >construct (at compile-time) to reconstruct the object from the >bit-stream. As David Brownell pointed out, all RPC systems solve this >problem. Masterson's proposal goes farther in that it posits shipping >the transitive pointer-closure of the object, while all RPC systems >that I know about require objects with "in-line" data. Dave is missing one vital point about O-O systems here - that of inheritence. Just because I declare a routine to accept an X at compile time does not mean that I am not free to pass a Y or Z in it place (providing Y and Z are derived from X). The implications of this (at least in a C++ context) is that the receiver wil construct the wrong receiveing type (always a base type and never the correct derived type) and hence all virtual functions will be dispatched incorrectly (from the senders point of view). Thus local and distributed versions of the same program will exhibit different behaviour! Graham Parrington, Computing Laboratory, University of Newcastle upon Tyne ARPA = Graham.Parrington%newcastle.ac.uk@nsfnet-relay.ac.uk UUCP = ...!ukc!newcastle.ac.uk!Graham.Parrington PHONE = +44 91 222 8067