From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!att!pacbell!ames!lll-winken!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard From: eberard@ajpo.sei.cmu.edu (Edward Berard) Newsgroups: comp.lang.ada Subject: Re: Objectification Summary: It's Not a Name I Invented Message-ID: <539@ajpo.sei.cmu.edu> Date: 8 Aug 89 12:54:50 GMT References: <534@ajpo.sei.cmu.edu> <15991@vail.ICO.ISC.COM> List-Id: In article <15991@vail.ICO.ISC.COM>, rcd@ico.ISC.COM (Dick Dunn) writes: > eberard@ajpo.sei.cmu.edu (Edward Berard) writes about many matters and > meta-matters roughly related to OOP and moving toward it. All well, but > couldn't someone come up with a better word (or perhaps I should just say > "a word") for the concept? "Objectification" is sufficiently ugly and > silly-sounding (sounds like it came out of a congressional committee) to be > an impediment to the goals. > ...Simpler is better. I very much agree that simpler is better. However, the discussion on "objectification" has been going on for some time now, and that is the term that people are using. For example, consider the following discussion which appeared on comp.lang.c++: --------------------------------- Subject: Re: Objectifying incoming messages? ^^^^^^^^^^^^ From: raph@tigger.planet.bt.co.uk (Raphael Mankin @ RT5111, BTRL, Martlesham Heath, England) (45 lines) More? [ynq] davidm@cimshop.UUCP (David Masterson) writes: >I'm working in an area doing C++ development that has several processes >communicating with one another. The messages shipped back and forth tend to >be asynchronous, so a receiving process cannot know what the message is or who >it came from until it looks at the message data. My question is this: >What is the appropriate method of taking a generic object (Message) and >turning it into an object of the type that is embedded in the message (say, >Employee)? Should this be done through virtual functions and subclassing of >the Message object? Or is it more appropriate to have the Message object look >at itself and construct an object of the appropriate type (perhaps some sort >of array of pointers to object constructors)? >The fundamental question hinges around the lack of context of the incoming >message. Therefore, the message user must look at the data in order to >determine what to coerce (definition?) the message into. Is this appropriate >or is there a better way? This is a fundamental problem of strongly typed languages. Ada pretends that it is not there but really has a worse problem than C++. Suppose you have a file with many variant records (unions) in it. You cannot allocate buffer space for the record until you know what type it is, and you cannot know what type it is until you have allocated space and read the record in. Ada does not permit you to read into a char* or (void*) and then cast the data when you have examined the non-variant header. The only way I have found of doing this in C++ is to go back to the old fashioned way of using a switch with a different cast in each branch. This is messy verbose and generally nasty. The only satisfactory solution is to allow types to be first-class objects so that we could have 'variable' casts. e.g. Type t = typelist[discriminant]; return (t)record_area; The run-time costs of this are horrible and I am not really suggesting it as a solution in C++. Does anyone have a sensible solution? Raphael Mankin raph@planet.bt.co.uk ---------------------------------- You will find discussions which use the terms "objectify," "deobjectify," "objectification," and "deobjectification" in a number of places. Typically, you will find them coupled with discussions of persistence, disk accessing, and OODBMS. By the way, a number of interesting solutions have also been proposed. -- Ed Berard (301) 353-9652