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.

> 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 polymorphism -

Actually, I don't think polymorphism is exactly the right word for thissituation, but since Bill originally started with the premisethat interfaces provide "more polymorphism" we've kept it in thediscussion. What is the right word? Maybe "roles" or somethinglike "temporarily aggregated functionality"? (TAF for short -- anew three-letter acronym! :-)

Some design methodologies and languagesmake a distinction between "type" -- the public interface ofsomething -- and "class" -- the kind of object that implementsthe behavior promised by that interface. A human piano player anda CD Walkman would both respond to "play it again, Sam" with similaroutputs but by very different methods.

> And then the previous example works,> if you replace the first line with:

>

> // example 2.2> BaseTalkative t;>

You're absolutely correct about all of this. And doesn't it bringa purer, more interface-like feel to the code?

> > 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).

Oops, sorry, I slipped up there; thanks for catching it.

Templates do provide so-calledcompile-time polymorphism, as opposed to the run-time polymorphismof inheritance and virtual functions. Checking validity at compiletime is considered a feature in C++. In Java it's so easy to losethe static type of an instance (because Hashtables only holdreferences to generic Objects, and so forth) that you're alwayshaving to use casts, and check for BadCastExceptions, and handlethem appropriately, etc. With C++ templates, that "cast" is doneat compile time, and saves writing a lot of code.

> And template do not really provide POLYMORPHISM.> When you write a template, the compiler creates a NEW class for> each Talkative 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 !

Again, I don't really like using the term polymorphism here. Actually,I think "interface" expresses more what I want, but since that hasspecific meaning in Java, it would just confuse the discussion. Iguess the point I want to make is that people are always comparingJava interfaces to C++ multiple inheritance, often with an arrayof abstract base classes (like COM), and decrying the complexityof this approach. In the last few years C++ compilers have becomeso much better at coping with templates, and programmers arediscovering new ways to think about using them to build elegantsolutions. (Now if the syntax could just be made simpler!)

> So we could have Dog and CuckooClock inherit BaseTalkative,> and throw the templates away...

Think about the issue of overhead. Once you add a new base classto the hierarchy, or a new Java interface, you're adding someburden to every descendant of that class. I'm talking about notonly more byte codes, but also the need to be careful of name conflicts further down the line, documentation overhead, fatterinterfaces leading to more complex interactions, . . . .

In contrast, a Talkative template doesn't add any overhead to theother class. All the documentation for Talkative-ness can bemanaged in one place, even for the specializations. And there'sa good chance that such minor functionality will be useful onlyin a well-defined locality in the code; why let it intrude intoevery other place where the class is needed?

> 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.

Everything I read indicates that Java must and will add some kindof generic-programming ability as it matures. Experience in Ada andC++ shows that it's too useful to ignore. Reserving the keyword"generic" is a big hint.

> Nope ! Private methods can be overriden without breaking the code,> since they are statically linked.

I hadn't realized that. I'll have to study how it works.

> > 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...

Isn't there a ClassLoader issue that comes into this? But themain obstacles are political rather than technical. You and six (orsixty!) other programming teams need to add some minor little interfaceto a class that all of you use. Who decides which additions get in?Who manages the documentation? Who handles change control?

> > 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.

Well, if the Java interface isn't there, things will still fail atsome point. (Although ObjectSpace is doing some very interestingthings with dynamic generation of class byte codes on the fly; checkout our web pages.)

> > 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 ?

It depends on how necessary the interface is to the life-cycle ofthe class. If it's only useful for a limited period of time, whyadd a permanent burden?

> > 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 !

Not a bit! It's great to have an exchange of ideas. This isespecially since I do most of my work in isolation and have todepend on email for technical discussions.

> Once again, I like this idea very much since it answers too rarely> asked questions.