Log in

No account? Create an account
Java is lame yet again - The Mad Schemes of Dr. Tectonic — LiveJournal [entries|archive|friends|userinfo]

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Java is lame yet again [Nov. 15th, 2006|03:44 pm]
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.

[User Picture]From: flwyd
2006-11-15 10:52 pm (UTC)
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.
(Reply) (Thread)
[User Picture]From: dr_tectonic
2006-11-15 11:24 pm (UTC)
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.
(Reply) (Parent) (Thread)
[User Picture]From: flwyd
2006-11-15 11:34 pm (UTC)
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...)
(Reply) (Parent) (Thread)
[User Picture]From: flwyd
2006-11-15 11:36 pm (UTC)
Did I say associative? I meant commutative.
(Reply) (Parent) (Thread)
(Deleted comment)
[User Picture]From: madbodger
2006-11-16 02:23 am (UTC)
Well, since Java is open source now, you could (theoretically) go and fix that little gaffe.
And discover the joys of unintended side effects.
(Reply) (Thread)
[User Picture]From: jofish22
2006-11-16 09:27 am (UTC)
Use a Mac!!

Oh, wait, no. Use Python!
(Reply) (Thread)
[User Picture]From: boat_of_car
2006-11-16 05:53 pm (UTC)
"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...
(Reply) (Thread)