Slashdot Mirror
Java Gets Templates
lastberserker writes "Call them all you want - generics, parametrized types, thingamagic mumbojumbo - but (tada!) Java gets templates in 1.5 release. Nice landing after 5+ years of dancing around a bush. Competition is good, pardon my pun."
Sounds like you don't get the point. The reason templates are useful is because it reduces the amount of code you need to write for common situations in a typesafe way. This makes your code more compact (duplicate code) and less error-prone (it's all type safe and you only write it once).
a d=6009 (lets hope /. gets this right). Lets hope all these goodies end up in 1.5.
BTW. generics are old news. The prototype compiler and the proposal have been available for at least a year. On the javalobby there's a link to some additional language extensions: http://www.javalobby.org/thread.jsp?forum=61&thre
Jilles
With that short a definition, the operator's meaning must be inferred by the reader's culture. + is the arithmetic sum operator. We know what it does after working with it for years.
Methods, on the other hand, can have extremely verbose names. That is one of the good things on the Java coding guidelines. Names are verbose. There's no strcmp. There's String.compareTo. If the compare is case insensitive, there's String.compareToIgnoreCase.
Objectively, you are right. There's no guarantee a function performs what its name implies. However, if a function's name is incorrect, I can smack the developer on the head. If an operator's name is incorrect, the developer may have done it right, since having an operator named multiplyTransposeAndNormalize is awkward. It's the whole concept of operator overloading that is wrong.
If at first you don't succeed, skydiving is not for you
Doing mainly C++ development I've learned to love the STL and most recently the Boost libraries and I've long regretted that Java didn't support templates. It always confused me that with as much emphasis was placed on strong typing in Java that there was so much need for casting.
Although I'm glad to see the introduction of templates, I'm also concerned about how some of the problems I've encountered with C++ templates will be avoided. The biggest problem I've encountered has been the lack of interface checking.
For example the templated function for_each(begin, end, function) iterates from 'begin' to 'end' calling 'function' on each item inbetween. However there is no mechanism to specify that the type of passed to 'begin' and 'end' must have an equality operator and an operator* and 'function' must take one parameter of the type returned by *begin. This can cause very strange compiler errors when a user tries to pass a variable that doesn't support the proper operations to be compatible with the function. These errors actually appear to occur within the templated code, not the user-written code and can make determining the cause of these errors very difficult.
The Boost Concept Check library provides a way for programmers writing templated C++ code to enforce the interface requirements on the templated parameters in a way that gives more informative error messages. However this is rarely used, even in the Boost libraries. The documentation on the Boost Concept Check gives a good example of the kind of errors that C++ programmers dread.
In order for Java templates to be successful they will need to provide some manner of enforcing requirements on the interface necessary for the templated code to work and provide useful errors at compile time if it doesn't.
Sorry, but I'm going to rant now, because every time I see this ill-informed argument it really annoys me.
Operator overloading is a fact of life when you are working with generics. Suppose I want to write a generalised summation method, which adds up all the elements in a list, whether those are int, float, SomeComplexNumberType or whatever. Question: what well-known and easily understood notation would make sense to use when writing this method? Should I write another method called add that has several versions, for each type I'd like to add up? Or maybe it should be addTo? After all, by your own argument, verbose and descriptive names are the way forward. But what if someone else provides a fixed-point type with a method called sum instead? Or maybe a static method taking two fixed-point values called sumOf? Do you see my point here? If everyone uses + to mean +, then writing such code is easy. If everyone uses different notation, which is forced if you don't allow operator overloading, then what you get is unmaintainable crap that cannot take advantage of generics in many of the most useful ways.
Java already has operator overloading anyway. You have + to concatenate strings. You have a conversion operator called toString. You have / that divides real numbers, but takes the integer part of the result for integral types. The only difference between these and what you have in a language like C++ is that in Java, you can only take advantage of this concept where the Java designers want you to, whereas in C++, you can write your own types at full strength as well.
Yes, operator overloading can be abused. So can method naming (and no, you can't smack the developer on the head, if he happens to work on the other side of the world and you're stuck using his library). But op overloading is more than mere syntactic sugar, where generic programming is involved. There are accepted standards for how we write certain concepts such as addition or strict ordering, and operator overloading is necessary to allow user-defined types to meet those standards, and thus to allow well-written generic code to take advantage of parameterised types and such to best effect. Without it, you've got a fabulous canvas, yet nothing but coarse paintbrushes to draw with.
Alas, as is so often the case, I fear the Java community has been too quick to think it understands, and to go for the buzzword feature without investigating the supports deeply enough. Parameterised types are a good start, and I'm glad to see them included, but I suspect that with experience, there'll be some serious enhancements in a couple of revisions' time...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Its sad how many ./ers dont truely understand o/o concepts or the many other cool features of Java. Hell many still think the only place Java exists is within Applets.
Although I agree with you, I must say that "understanding object orientation" amongst programmers is little like "understanding humour" amongst ordinary people. Everybody think they do.
Any language (that I know of, and that is quite a bunch) can be used to write "proper OO code" aswell as plain-old imperative programming.
I think Alan Cox put it well when he said "object orientation is a state of mind". Linux kernel is really object oriented on many many levels.
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
Too late:
Sun ignored requests from the developer community to extend the Java core language. Now they finally listen, after Microsoft copied Java with C# and added generics. This is why Java has gone from the hottest thing since Starbucks, to yet another language. They didn't listen to their user base until 2 years after it was too late.
Lessons learned:
This is also why Microsoft is so successful - they constantly innovate, rather than sitting on their market dominance. I foresee Sun suddenly trying to play catch-up with new core Java features. I will enjoy reading the spin Sun puts on this, after saying for years that none of these features were necessary.
Until it has that it is obviously not complete!
It's 10 PM. Do you know if you're un-American?
You should be able to write this as:
/* now we can do this: */
/* because we can be sure that e implements comparable */
class MySortedList<Element implements Comparable> {
void insert(Element e) {
int i = e.compareTo(another_element);
}
}
What a fool believes, he sees, no wise man has the power to reason away.