PROPOSAL: Simplified StringBuffer/StringBuilder syntax

Reinier Zwitserloot reinier at zwitserloot.com
Tue Mar 31 05:59:33 PDT 2009


+ being overloaded to also mean string concatenation was a mistake in  
java 1.0*. Let's not enshrine it by making more of them.

Also, if '+' will call .append on any appendables, I guarantee you,  
the first thing some clown will create is this:

public class BigInteger2 extends Number implements Appendable {
    //I'm a BigInteger that supports +! Oh - and I'm mutable too :/
}


Specific problems with the entire concept:

1. + so far is strictly a 'create new object with result' kind of of  
operation. "x + y" is an expression that does not change either the  
value of x, or the value of y. It just creates a new value, and that  
is the result of the expression. The same thing happens with strings,  
but if you apply this to appendables, all of a sudden you get "x + y"  
takes y and appends it to x. That is just strange.

2. The whole point of not allowing operator overloading is to make  
sure any given snippet of the form 'x + y' serves as an anchor of  
sorts: You know nothing too weird is going on in those 3 characters.  
If + can mean: Mathematical plus, -OR- string concatenation (utterly  
unrelated), -OR- anything anybody may have cooked up by implementing  
Appendable, then there's zero conservative anchoring left for the +  
symbol. Ergo I assert that doing this is as bad as having full blown  
operator overloading. Actually, it's worse - at least full blown  
operator overloading has proper names for things ('+' is plus and not  
append), and allows one to write proper libraries for it.

*) string concat and numeric plus are unrelated to each other. In  
fact, numeric plus ought to be commutative, which string concat isn't  
(commutative = swapping arguments doesn't change result). It weakens  
the information that a raw + sign is capable of telling you. There are  
pros and cons to having a strict interpretation of a + sign, but given  
that java does not allow operator overloading, the onus appears to be  
on those in favour of weakening it to prove why this is acceptable.

  --Reinier Zwitserloot



On Mar 28, 2009, at 21:14, Mark Thornton wrote:

> Derek Foster wrote:
>>
>> CONCATENATION: An expression of the form
>>
>>    SB += S
>>
>> where SB is an RValue expression of type StringBuilder, and S is an  
>> expression of type String, shall be considered to have meaning as  
>> defined below. (Previously, this was a syntax error)
>>
>> SELF-CONCATENATION:
>>
>> An expression of the form
>>
>>    SB = SB + S
>>
> Why not allow any Appendable in these cases?
>
> Mark Thornton
>




More information about the coin-dev mailing list