Java is lame yet again

[dr_tectonic]

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

[flwyd.livejournal.com]

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.

[dr-tectonic.livejournal.com]

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.

[flwyd.livejournal.com]

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

[flwyd.livejournal.com]

Did I say associative? I meant commutative.

[madbodger.livejournal.com]

Well, since Java is open source now, you could (theoretically) go and fix that little gaffe.
And discover the joys of unintended side effects.

[jofish22.livejournal.com]

Use a Mac!!

Oh, wait, no. Use Python!

[navrins]

Except append() is a statement and + is part of an expression. So I think you really want '+=' to be shorthand for append(), not '+'.

In more concrete terms,

StringBuffer sb;
sb += "!";

should be the equivalent of

sb.append("!");

It doesn't make sense to say,

sb + "!";

and I can't see why you'd want to say

sb2 = sb + "!";

though I suppose you might (but that's not the equivalent of append() anyway since append() modifies sb, and nobody expects '+' to have side effects).

I'm not really disagreeing with your rant; I'm just nitpicking it.

[boat-of-car.livejournal.com]

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