NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/cplus/16197

Internet Message Format | 1992-11-13 | 3.3 KB

Path: sparky!uunet!know!cass.ma02.bull.com!mips2!news.bbn.com!usc!cs.utexas.edu!convex!news.utdallas.edu!corpgate!crchh327!bnr.ca!holiday
From: [e-mail] (Matthew Holiday)
Newsgroups: comp.lang.c++
Subject: Re: Discriminating Variant Records Without switch() ??
Message-ID: <[e-mail]>
Date: 12 Nov 92 19:05:18 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: holiday@crchh82 (Matthew Holiday)
Reply-To: [e-mail]
Organization: Bell-Northern Research, Richardson, TX
Lines: 48
Nntp-Posting-Host: crchh82

In article <[e-mail]>, [e-mail] (Brian Button) writes:
|>
|> In article <[e-mail]>, [e-mail] (Brian Button) writes:
|> |> Is there a simple, OOP based way to discriminate between variant
|> |> records? I saw an article in C Users Journal last month titled "Switch
|> |> Deemed Harmful to C++" or something like that, but I couldn't figure
|> |> out how to do it any other way.
|>
|>
|> ->"Matthew" == Matthew Holiday <[e-mail]> writes:
|>    Matthew> switch statement! :-) There ought to be a convenient way
|>    Matthew> to create objects from network messages, i.e., some way to
|>    Matthew> register message types and their matching class types,
|>    Matthew> such that for every incoming message, its body (an array
|>    Matthew> of bytes) gets turned into the correct object, which would
|>    Matthew> be derived from a root generic message object.
|>
|> There is such a way using factory classes such as the RogueWave
|> RWFactory class. The problem I'm having is figuring out how to deal
|> with these objects after they are already created. Since there's no
|> common set of operations which are performed on each of the objects,
|> there is no set of methods which may be made virtual and overloaded.
|> Herein lies the problem. This seems to point towards using special
|> purpose code for each class, which would necessitate using a switch.
|>
|> Have I painted myself into a corner or is there some way out. How are
|> the rest of you OOP programmers dealing with cases like this?
|>

One thing that would help would be the ability to "transmute" an object into
a subclass of the object's current class.  That is, the factory could create
a top-level object.  After some processing, this object could determine that
it's really more specialized, and turn itself into a subclass object.  Take a
trivial example: a shape is constructed using some points.  Further processing
reveals that the points define a rectangle, so the shape converts itself into
a rectangle.  Yet more processing reveals that the rectangle is in fact a
square -- so it becomes an object of type square, which was derived from
rectangle and shape.  One of the problems with this downward transmutation is
that if you simply replace the object, it will have a new address, so you have
to update all pointers to the object every time it is replaced.  You can't
necessarily transmute in place, because the new subclass object may be too
large to fit into its current space in memory.  In addition to this "transmute"
capability, downcasting is also useful (see Stroutrup's RTTI papers).

--
Matt Holiday                                      #include <std/disclaimer>
[e-mail]
BNR Richardson, TX