Convert String and List to abstract classes.

Convert String and List to abstract classes.

Removes StringImplementation and ListImplementation which were
just containers for static/factory methods.

Split into two parts, with String landed now and List being worked on. This CL is closed.

[Lasse Reichstein Nielsen, 2012-09-19 12:33:21]

There are some references to "ListImplementation" left in the VM code.
One in tests/vm/dart/isolate_mirror_local_test.dart. I'll see if it should just
be removed.
And one in vm/flow_graph_builder.cc which tests a class name against
Symbol::ListImplementation, possibly as an optimization, since co19 and language
tests run without problem.

[Lasse Reichstein Nielsen, 2012-09-19 14:21:02]

Ack, there is more wrong with this. It also fails both of:
 vm/cc/DartGeneratedListMessages
 vm/cc/DartGeneratedListMessagesWithBackref
due to some id that's expected to be kArray being kUnsupported.
There's probably some type test somewhere that should be changed.

[srdjan, 2012-09-28 17:52:22]

Lasse, can you please split List and String conversions into two different CLs

https://codereview.chromium.org/10942025/diff/4001/lib/core/collection.dart
File lib/core/collection.dart (right):

https://codereview.chromium.org/10942025/diff/4001/lib/core/collection.dart#n...
lib/core/collection.dart:35: Dynamic reduce(var initialValue,
Why not remove Dynamic everywhere?

https://codereview.chromium.org/10942025/diff/4001/runtime/lib/array_patch.dart
File runtime/lib/array_patch.dart (right):

https://codereview.chromium.org/10942025/diff/4001/runtime/lib/array_patch.da...
runtime/lib/array_patch.dart:8: /* patch */ factory List([int length = null]) {
Shouldn't the 'patch' be enabled here, since:

external factory List([int length]);

[Lasse Reichstein Nielsen, 2012-09-30 20:46:43]

Good idea. I'll split this up when I get back from GOTO;

https://codereview.chromium.org/10942025/diff/4001/lib/core/collection.dart
File lib/core/collection.dart (right):

https://codereview.chromium.org/10942025/diff/4001/lib/core/collection.dart#n...
lib/core/collection.dart:35: Dynamic reduce(var initialValue,
"var" is not a valid return type, and I don't like not writing a return type
(looks like an omission).

https://codereview.chromium.org/10942025/diff/4001/runtime/lib/array_patch.dart
File runtime/lib/array_patch.dart (right):

https://codereview.chromium.org/10942025/diff/4001/runtime/lib/array_patch.da...
runtime/lib/array_patch.dart:8: /* patch */ factory List([int length = null]) {
I was informed that the patch parser in the VM does not support "patch" on class
members. The patch class member overrides the original class member in all
cases. The /* patch */ is used for documentation.

[srdjan, 2012-10-02 17:21:14]

https://codereview.chromium.org/10942025/diff/4001/lib/core/collection.dart
File lib/core/collection.dart (right):

https://codereview.chromium.org/10942025/diff/4001/lib/core/collection.dart#n...
lib/core/collection.dart:35: Dynamic reduce(var initialValue,
On 2012/09/30 20:46:43, Lasse Reichstein Nielsen wrote:
> "var" is not a valid return type, and I don't like not writing a return type
> (looks like an omission).

This is not the the style that has been used by most people in Dart team
(checked with Ivan and Bob). It is important that we have a unified style in the
libraries.I.e., rather than "Dynamic foo(var a, var b)", we should write "foo(a,
b)"

[Mads Ager (google), 2012-10-02 17:33:07]

On 2012/10/02 17:21:14, srdjan wrote:
> https://codereview.chromium.org/10942025/diff/4001/lib/core/collection.dart
> File lib/core/collection.dart (right):
> 
>
https://codereview.chromium.org/10942025/diff/4001/lib/core/collection.dart#n...
> lib/core/collection.dart:35: Dynamic reduce(var initialValue,
> On 2012/09/30 20:46:43, Lasse Reichstein Nielsen wrote:
> > "var" is not a valid return type, and I don't like not writing a return type
> > (looks like an omission).
> 
> This is not the the style that has been used by most people in Dart team
> (checked with Ivan and Bob). It is important that we have a unified style in
the
> libraries.I.e., rather than "Dynamic foo(var a, var b)", we should write
"foo(a,
> b)"

Dynamic is unnecessary as a return type and I agree that we should leave out the
return type instead. Why add an optional type when it means the same as leaving
it out? I think we should limit the use of Dynamic as much as possible.