PROPOSAL: Simplified StringBuffer/StringBuilder syntax

[Ruslan Shevchenko]

> Catching up on proposals...
>
> Derek Foster wrote:
>> Simplified StringBuffer/StringBuilder syntax.
>>
>> AUTHOR: Derek Foster
>>
>>
>> OVERVIEW
>>
>> The Java language is designed to use immutable strings. Strings are
>> intended to be constructed via one of two builder classes: StringBuffer
>> (older, and slower due to synchronization) and StringBuilder (newer, and
>> faster). Using these classes can make constructing Strings out of
>> multiple pieces considerably more efficient than repeatedly
>> concatenating strings together. These classes are often used by the Java
>> compiler to concatenate strings behind the scenes, so that an expression
>> like this:
>>
>>     String foo = "abcd" + 42 + "efgh";
>>
>> might be compiled as:
>>
>>     String foo = new StringBuilder("abcd").append(42).append("efgh");
>>
>
> The subset of this proposal I'm most sympathetic to is having ""+=" on
> StringBuffer and StringBuilder desugar into a call to append.  Offhand,
> I think that could be a mostly localized specification change that
> indicated the String{Buffer, Builder} was being mutated.  Coming up with
> String => StringBuffer conversion rules in assignment contexts is
> possible, but not necessarily desirable IMO.
>
> An analysis of the applicability of just this change to a corpus of code
> might be informative.
>

Is this any call of StringBuilder.append() ?
Ok, I will add one.

Btw, personally I'm not big fun of this proposal, because this is attempt
 to solve small part of big problem by special partial rule.

I. e. real problem - absence of operator overloading. Some partial solutions
are index access and overloading of '+=' for string builders.
 May be I can imagine, that special rules for index access expressions
instead describing operator overloading is not very-very wrong way
(justified by 80/20 case, as foreach without closures ), but special rule
in language for each type  when we need operator overloading ?

 So, for me sense of existence of such approach is be argument to add
operator overloading in post-coin phase (Java 8 (?)).


> -Joe
>
>