|
This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Artima Forums.
Message:
C++ templates don't provide polymorphism
Posted by Pierre-Antoine Champin on 08 Dec 1998, 12:20 AM
Dear Lois, I liked a lot your way of using C++ Templates.
But I think there is a little problem with your example :
it does not REALLY provide pomymorphism - you can't write :
// example 1
Talkative t;
t = makeTalkative(aDog); t.talk();
//...
t = makeTalkative(aCuckooClock); t.talk();
The first line is incorrect - or am I wrong ?
But your idea still works if you write :
// example 2.1
class abstract BaseTalkative {
abstract void talk();
};
template
class Talkative public: BaseTalkative {
T& t;
public:
void talk() { /*...*/ }
};
And then the previous example works,
if you replace the first line with:
// example 2.2
BaseTalkative t;
> The C++ template approach has the advantage that run-time
> polymorphism can be attached to a class object without requiring
> any change to that class's code. Huho ! This is definitely not RUNTIME polymorphism.
Templates work because you know at COMPILATION time that all the
classes you use for T do have a talk method (and for those which
don't, you provide it by naming the classes, still at compilation
time). And template do not really provide POLYMORPHISM.
When you write a template, the compiler creates a NEW class for
each Talkative<SomeClass> that you write.
And those classes have nothing in common a priori, that's why
example 1 doesn't work !
If example 2 provides polymorphism, it's not thanks to templates,
but thanks to the common abstract ancestor - which is much
comparable to Java interfaces ! So we could have Dog and CuckooClock inherit BaseTalkative,
and throw the templates away...
But I still find your idea is great :) Here's why > You could argue that adding "implements Talkative" to the class
> definition is useful for documentation purposes. But you could
> also argue that it is intrusive on the design of domain classes,
> and modifying source code which you do not "own" or which others
> share is sometimes undesirable or impossible for various reasons.
> ...
> Even creating a new Java
> subclass to add Talkative-ness to some domain object can be
> impossible if most classes are declared final (as is recommended
> by another article in JavaWorld). That's the great point !
This is a start of solution in the problem of "inheritance insertion"
which I reaised in another mail on this list !
You can add (compilation-time) polymorphism to classes with different
origins, even without having access to their source code. > If an unrelated (possibly
> unnoticed because private) talk() function is defined by some
> class in the hierarchy, overriding that function to implement the
> Talkative interface could break existing code. Nope ! Private methods can be overriden without breaking the code,
since they are statically linked. > And there is also
> the political issue of whether the Talkative subclass should be a
> member of the same package as its base, or of some other package
> which you "own." Not a real problem : you can actually write classes in packages
you don't own - even java.lang if you like to !
I discovered it not so long ago in a Javaworld article ;)
Create in your package directory a new dir java/lang and add your
classes into it. You can even use your own version of String or
Object instead of sun's, but that's another story... > To drive into the ground the argument that C++ templates provide
> even more flexibility than Java interfaces, template classes can
> also define member variables and additional functionality not
> related to the class of the template argument. Which allows you to attach them to classes which don't have the
talk() method. But once again, it's only usable at compilation time. > They are like
> interfaces which can be attached to classes for limited purposes
> and periods of time. What is the point of attaching an interface for a limited period of
time ? > I'm writing to you not to be critical of Java or to start a flame
> war over religious issues, but simply to point out that there are
> mechanisms in C++ which work differently from Java, but still
> work. I think it's more interesting and educational to study the
> differences between the best mechanisms of different languages,
> than to look at comparisons where one of the elements is
> artificial or unidiomatic. I fully agree with this.
I hope you didn't read that mail as a flame !
Once again, I like this idea very much since it answers too rarely
asked questions. Pierre-Antoine
Replies:
|
