Re: Objectification

[eberard@ajpo.sei.cmu.edu (Edward Berard)]

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