Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!ames!amdahl!fai!kurtl
From: kurtl@fai.UUCP (Kurt Luoto)
Newsgroups: comp.object
Subject: Re: Pre-computing objects
Summary: no answers yet
Message-ID: <2561@fai.UUCP>
Date: 30 Oct 89 18:45:15 GMT
References: <4671be53.20b6d@apollo.HP.COM>
Reply-To: kurtl@fai.fai.com (Kurt Luoto)
Organization: Fujitsu America, Inc
Lines: 89

In article <4671be53.20b6d@apollo.HP.COM> vinoski@apollo.HP.COM (Stephen Vinoski) writes:
>
>  This problem seems pervasive; other examples are reading objects from disk
>storage and receiving objects from another process.  Basically, how does one
>know what type of object to construct to receive the object unless the type of
>the blob coming in from the external source is already known?  This appears to
>be one area of OOP that requires something like a switch or case statement to
>work properly.
>
>  Doesn't Meyer's method trade the maintenance woes of a switch or case
>statement for having to maintain the initialization function for the command
>object array?  It's a good tradeoff, but isn't there anything better?  It also
>seems that his method is appropriate only for collections of objects which are
>somehow related.
>
>-steve
>
>| Steve Vinoski       | Hewlett-Packard Apollo Div. | ARPA: vinoski@apollo.com |
>| (508)256-6600 x5904 | Chelmsford, MA    01824     | UUCP: ...!apollo!vinoski |

I have also run into this problem (translating external messages
into objects) while working in C++, and I could think of nothing
more pragmatic at the time than the equivalent of Meyer's solution,
i.e. a table lookup based on message type.  Indeed, it seems that at
least C++ (and apparently Eiffel) does not help to "distribute the case
statement" in this situation as it does for virtual functions.

There are other related situations that I have run into where the
C++ language could not provide any magic:
    
    I.  I have a particular inheritance tree of classes. The instances
	of these classes are small in size and high in volume.  Further-
	more, I would like to define virtual functions for them. However,
	in current implementations of C++, using the language-provided
	virtual function mechanism involves an extra storage overhead
	of a pointer (to a vtable) per object. While this is perfectly
	acceptable in most cases, it is not in this case because of the
	large number of instances. Hence I have to avoid the language
	provided mechanism. I can easily tell the class of an object by
	the value of a tag field. C++ could have provided a way for me
	to tie the value of this field to its class, and thus provide a
	alternate mechanism for discriminating virtual functions at runtime.
	However, the author(s) of C++ wisely left out such a provision.
	I must resort to putting case statements in the (now non-virtual)
	member functions, or resort to non-standard hackery to simulate
	virtual functions based on a tag field.

    II. I have a particular inheritance tree of classes. A client module
	needs to allocate storage in a particular place for an instance
	of one of these classes. The client needs to allocate a buffer
	large enough to hold an instance of any class in the tree. But
	we would like to not have to burden the client code with explicit
	knowledge about all classes. The pragmatic solution is to create
	a header file which defines a union type. The union contains
	members for all classes in the hierarchy. This is a good solution,
	but now we need to remember to update this header file every
	time we introduce a new class to the tree. It does not seem
	reasonable to expect C++ to handle this more gracefully, given
	its C-like separate compilation facilities.

In both of these situations, the pragmatic solution is less than elegant.
I would not propose changing C++ to better handle these cases, but I can
imagine how another language might simplify them.  Both cases would seem
to require that the compiler/system know about all the classes in the
inheritance tree, even when the client module under compilation only
refers to the root class of the tree.  This is not normally true in C++,
but it is probably true in at least some other languages.  Given the
availability of such knowledge, the compiler could pick off the information
that it needs, such as the size of an instance of each class and therefore
the maximum size over the overall tree.  To handle the first case above,
the language could provide a way for the programmer to enter the tag field
value (or some other discriminating information) into or along with the
class declaration itself. The compiler could then generate appropriate
code for runtime determination of the proper virtual function.

It seems to me that such a language could also help simplify the problems
that Stephen has run into. In the case of external messages, the "tag field"
class identification method would be extended to allow the programmer to
define a "default class" that would handle otherwise invalid tag field
values.

So, from my humble experience, there are no easy answers, at least not as
long as you're working with C++. But it is interesting food for thought.

P.S. Sorry for the length of the posting.
-- 

----------------
Kurt W. Luoto     kurtl@fai.fai.com   or   ...!sun!fai!kurtl