Removal of StringBuffer clear reduces the usage using final on a StringBuffer .

[terrylucas]

Noticed with M3 deprecation of clear method it is no longer possible to use one StringBuffer for building up a string. For example:

class A {
  final StringBuffer buff = new StringBuffer();
  String emitToDebug() => buff.toString();
  void reset() { buff.clear; }
}

must now be:

class A {
  StringBuffer buff = new StringBuffer();
  String emitToDebug() => buff.toString();
  void reset() { buff = new StringBuffer(); }
}

Unfortunate, that I can't use final and must allocate the extra object (StringBuffer) to empty my StringBuffer.

I vote to bring back clear().

[anders-sandholm]

Added Area-Library label.

[anders-sandholm]

Added Triaged label.

[DartBot]

This comment was originally written by @paulevans

---

Indeed, bring back clear.

Removing clear encourages extra allocations that give the vm more work to do. Depending on how the vm works it may not even be able to collect many composed strings in a context.

A server application that mutates many strings - or a game displaying a simple thing like framerate - could get performance penalties / frame hitches from this.

[DartBot]

This comment was originally written by @paulevans

---

See Issue #1216: StringBuffer in JavaScript is much slower than String https://code.google.com/p/dart/issues/detail?id=1216

If those figures of 86% hold true still I can see why they would want to sour StringBuffer

[floitschG]

The deprecation mark on "clear" has been removed with r19930.

---

Added Fixed label.