| Java is lame yet again |
[Nov. 15th, 2006|03:44 pm]
Beemer
|
Things to hate about Java, #5801:
I get why Java has both Strings and StringBuffers. There are advantages to each, and times when you want to use one rather than the other.
Like, if you're building a long string up out of a lot of little pieces, it's a whole lot more efficient to do it with a StringBuffer, which is designed for that kind of thing, than do it with Strings, because they're immutable and the '+' operator gets translated invisibly into a temporary StringBuffer and some calls to append(), so why not do it that way explicitly in the first place, right?
So, given that the number-one usage of StringBuffer is almost certain to be to concatenating a bunch of Strings together, and given that StringBuffer is just as much a part of the Java language core as String, and given that you can use the '+' and '+=' operators on Strings...
Why in the name of all that is holy is '+=' NOT aliased to 'append()' for StringBuffers?
Argh, I say. Argh. |
|
|
| Comments: |
Because String + is already a concession?
Since Java is all passed by-value, a += b doesn't modify in place, but is really just shorthand for
a = a + b
And when a is a StringBuffer and b is a String, that turns into
a = a.toString().concat(b)
which is what you're trying to avoid in the first place.
That's fine, but it seems to me that it would make infinitely more sense for '+' on a StringBuffer to be shorthand for append() than for it to be shorthand for "convert it to a String and then concatenate it with the RHS".
I mean, what other interpretations are there for applying + to a StringBuffer than append()?
If we're adding enough inconsistent syntactic sugar to apply + to String, there's no reason not to apply it to StringBuffer, as well.
String addition is weird anyway. Unlike almost every other addition context, String + is not associative, so a + b != b + a (except in the case where one or both are the empty string or are identical). Furthermore, both int + String and String + int produce a String. This is in keeping with the fact that int + double and double + int return doubles, not ints. But it also means that Object + String and String + Object both produce Strings. Which restricts the ability to add operator overloading in the future in a sane way while maintaining backward semantics. (E.g. you can't dynamically dispatch + to the first argument unless you have Object declare a final +(String) implementation. And then objects can subtract Strings, but not add them...)
Did I say associative? I meant commutative. (Deleted comment)
Well, since Java is open source now, you could (theoretically) go and fix that little gaffe.
And discover the joys of unintended side effects.
Use a Mac!!
Oh, wait, no. Use Python!
"Well, since Java is open source now, you could (theoretically) go and fix that little gaffe.
And discover the joys of unintended side effects."
Oh, I would *so* go back and re-learn Java if it were Beemerized: just think of all the wise and unique things it could do...and, as a bonus, it would have a really cool mustache... | |
