Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!att!cbnewsl!marks From: marks@cbnewsl.ATT.COM (mark.e.smith) Newsgroups: comp.lang.c++ Subject: Re: Design Problem Summary: polymorphism/parameterized types Message-ID: <3311@cbnewsl.ATT.COM> Date: 15 Dec 89 05:10:18 GMT References: <22137@brunix.UUCP> <192@paradim.UUCP> Organization: AT&T Bell Laboratories Lines: 34 > > them define a particular function and some of them don't, and I want to > > invoke the function on only those objects for which it is defined. .... > > > > It seems I have three possible approaches: > > 1. Define evaluate() as a virtual function in ARC, and redefine it > > appropriately in EXECUTABLE_ARC. In ARC, make it a noop, so when > > called on NONEXECUTABLE_ARCs, it won't do anything. > > < other stuff > > Another approach is to insure that only instances of EXECUTABLE_ARC > are inserted into a collection. You are then assured that all members > of the collection, including public subclasses, have evaluate() defined. > > This will require redesigning the solution to your problem at a higher > level. For example, two collections may be required to manage the > two fundamental ARC classes. The goal is to use polymorphism to your > advantage instead of reverting to C "switch" approaches or to de-tune > your class definitions. (Yes. And add to that casting.) Many times, the "natural" way of doing this is with parameterized types, where each collection can only have members of one class hierarchy on it. The base for a particular hierarchy defines the "weird" functions not shared with more general superclasses. But the collection operations are then shared across all the class hierarchies. As of right now, parameterized types can only be done with macros (referred to as "generic classes"), but I hope that changes sometime fairly soon. Having gone through extensive production code using generic classes, I find the benefit of being able to specify parameterized types is evenly balanced by the drawback of having to manage those nasty macros. Mark Smith gc3ba!mark