Replace StringBuffer and Strings with List.toString and List.join

[DartBot]

This issue was originally filed by @seaneagan

---

StringBuffer and Strings.concatAll could be replaced by a toString method in List which returns the concatenation of the result of toString() of each element in the list.

Similarly Strings.join could be replaced by a join method in List.

In addition to shrinking the core library, these changes also shrink string concatenation code by using instance rather than static methods:

list.toString();
// vs
Strings.concatAll(list);

list.join(separator);
// vs
String.join(list, separator);

[DartBot]

This comment was originally written by drfibonacci@google.com

---

Removed Type-Defect label.
Added Type-Enhancement, Area-Library, Triaged labels.

[floitschG]

We will have to make a choice:
1- current behavior (which redirects to Object.toString). We don't like it, so there is little chance it will stay this way.
2- [el1, el2].toString returns "[el1, el2]".
3- List.toString acts like StringBuffer (your suggestion).
4- mixture of 2 and 3. toString as in 2, but remove StringBuffer and simply add .join to List. StringBuffer would then need to be "finalized" with sb.join().

Note that StringBuffer normally calls 'toString' right away on the argument of 'add'.
A list can't do that. Only during 'join' and 'toString' would it be able to do that. So there is a semantic difference.

[DartBot]

This comment was originally written by @seaneagan

---

To me, the lazy toString() semantics seem better. You avoid the stringification of the individual elements until actually needed, similarly to how the actual concatenation is avoided until actually needed. Also, if an object is updated after being added to a string buffer, such that its toString result is changed, chances are you want the new result, not the old.

If one desires eager toString semantics they can simply use a List<String>, and call toString() on any non-String elements before adding them, which is the less common case.

Thus, I think replacing StringBuffer and Strings with the following addition to the List implementation is the best solution:

join(String separator) native;
toString => join('');

[DartBot]

This comment was originally written by @seaneagan

---

A couple improvements:

1. move "join" to Collection instead of List. Python allows joining any iterable, which is nice (see http://docs.python.org/library/stdtypes.html#str.join)
2. make separator optional, default to empty string to get Strings.concatAll / StringBuffer (except lazy) behavior. Then List.toString is free to do something else.

To summarize, just replace StringBuffer and Strings with Collection.join:

  join([String separator/* = ''*/]);

[DartBot]

This comment was originally written by thebinarysearc...@gmail.com

---

It should be noted that while Dart's implementation of StringBuffer is useless compared to maintaining and joining a list of strings, other implementations (Java) have convenient methods such as deleteCharAt(int index) which are more tedious when maintaining the list of strings yourself.

Also, as an out-there idea, maybe implement a Joinable interface that determines what happens when you join a list of objects of a particular type.. though this may be impossible. I was just thinking, List<Point> points; points.join() should really return a line or shape or something, not a string...

[lrhn]

I think we should either give Collection.toString an optional "separator" parameter, or add a "join" method to Collection. The former doesn't play well with the default toString of, e.g., List which adds '[' and ']' around the output, so 'join' is probably the best solution.

The Strings class must be destroyed. Its only reason to exist was that the initial library wanted String to be an interface, not a class.

---

Added this to the M2 milestone.
Added Accepted label.

[floitschG]

Removed this from the M2 milestone.
Added this to the M3 milestone.

[rakudrama]

Regarding comment 7.

I do like Python's attachment of this functionality to String.

   ', '.join(['cat', 'dog', 'mule']) ==> 'cat, dog, mule'

One thing I like about this is that since the receiver is a String, it is reasonable to .toString() the Iterable's elements. join on Collection could be some other kind of join, e.g. as in a database.

[anders-sandholm]

Removed this from the M3 milestone.
Added this to the M4 milestone.

[lrhn]

We now have Iterable.join with a separator.

---

Added Fixed label.