- Remove redundant type parameters for internal data.

- Remove redundant type parameters for internal data.
Committed: https://code.google.com/p/dart/source/detail?r=18287

[siva, 2013-02-08 23:13:34]

lgtm

https://chromiumcodereview.appspot.com/12218082/diff/1/lib/growable_array.dart
File lib/growable_array.dart (right):

https://chromiumcodereview.appspot.com/12218082/diff/1/lib/growable_array.dar...
lib/growable_array.dart:13: T result = this[index];
can this just be:
var result = this[index];
(the type check will happen on the return statement).

https://chromiumcodereview.appspot.com/12218082/diff/1/lib/growable_array.dar...
lib/growable_array.dart:114: List<T> result = new _GrowableObjectArray<T>();
var result = new ...
just like how it is done in factory _GrowableObjectArray

https://chromiumcodereview.appspot.com/12218082/diff/1/vm/object.cc
File vm/object.cc (right):

https://chromiumcodereview.appspot.com/12218082/diff/1/vm/object.cc#newcode11870
vm/object.cc:11870: StorePointer(&(raw_ptr()->data_), new_contents.raw());
Ditto.

https://chromiumcodereview.appspot.com/12218082/diff/1/vm/object.h
File vm/object.h (right):

https://chromiumcodereview.appspot.com/12218082/diff/1/vm/object.h#newcode4670
vm/object.h:4670: virtual RawAbstractTypeArguments* GetTypeArguments() const {
Should we assert here that
Array::Handle(data()).GetTypeArguments()
is null now.
(we don't want some random type being set here).

[Ivan Posva, 2013-02-08 23:27:32]

https://chromiumcodereview.appspot.com/12218082/diff/1/lib/growable_array.dart
File lib/growable_array.dart (right):

https://chromiumcodereview.appspot.com/12218082/diff/1/lib/growable_array.dar...
lib/growable_array.dart:13: T result = this[index];
On 2013/02/08 23:13:34, siva wrote:
> can this just be:
> var result = this[index];
> (the type check will happen on the return statement).

Agree with you that we should rip out ALL of the types inside the methods here,
like it is suggested for good Dart code. But that should be a different change.

https://chromiumcodereview.appspot.com/12218082/diff/1/lib/growable_array.dar...
lib/growable_array.dart:114: List<T> result = new _GrowableObjectArray<T>();
On 2013/02/08 23:13:34, siva wrote:
> var result = new ...
> just like how it is done in factory _GrowableObjectArray

Again, as above the removal of types in the bodies is a different CL.

https://chromiumcodereview.appspot.com/12218082/diff/1/vm/object.cc
File vm/object.cc (right):

https://chromiumcodereview.appspot.com/12218082/diff/1/vm/object.cc#newcode11870
vm/object.cc:11870: StorePointer(&(raw_ptr()->data_), new_contents.raw());
On 2013/02/08 23:13:34, siva wrote:
> Ditto.

ditto.

https://chromiumcodereview.appspot.com/12218082/diff/1/vm/object.h
File vm/object.h (right):

https://chromiumcodereview.appspot.com/12218082/diff/1/vm/object.h#newcode4670
vm/object.h:4670: virtual RawAbstractTypeArguments* GetTypeArguments() const {
On 2013/02/08 23:13:34, siva wrote:
> Should we assert here that
> Array::Handle(data()).GetTypeArguments()
> is null now.
> (we don't want some random type being set here).

Actually we don't and shouldn't care about the type being set on the backing
store.

[siva, 2013-02-08 23:32:28]

https://chromiumcodereview.appspot.com/12218082/diff/1/vm/object.h
File vm/object.h (right):

https://chromiumcodereview.appspot.com/12218082/diff/1/vm/object.h#newcode4670
vm/object.h:4670: virtual RawAbstractTypeArguments* GetTypeArguments() const {
I disagree, if the data is irrelevant then that field should not be there (have
a different representation for the backing store which is more tedious) or if we
have it then make it a sane value so that we know what to expect when we are
debugging heap trashes or some similar nasty bug.


On 2013/02/08 23:27:32, Ivan Posva wrote:
> On 2013/02/08 23:13:34, siva wrote:
> > Should we assert here that
> > Array::Handle(data()).GetTypeArguments()
> > is null now.
> > (we don't want some random type being set here).
> 
> Actually we don't and shouldn't care about the type being set on the backing
> store.