Removing more dom_ methods.

Removing more dom_ methods (dom_getAttribute and dom_setAttribute.).
BUG=
R=blois@google.com

Committed: https://code.google.com/p/dart/source/detail?r=26928

[Emily Fortuna, 2013-08-23 21:02:05]

I did performance tests, and could not find any difference between the $dom
version and the public method of accessing these properties. So I'm switching to
the public version.

There is one additional possible spot for speedup. In the
impl_Element.darttemplate, the gettor for "attributes" creates a new
AttributeMap every time. I have a version of this CL that caches that instead
once it's been created, but like I said, this one seemed to be fine on
performance, so I didn't add it here.

[Emily Fortuna, 2013-08-27 16:01:20]

ping?

[blois, 2013-08-27 16:08:10]

https://codereview.chromium.org/23189014/diff/3001/samples/third_party/dromae...
File samples/third_party/dromaeo/tests/dom-attr-html.dart (left):

https://codereview.chromium.org/23189014/diff/3001/samples/third_party/dromae...
samples/third_party/dromaeo/tests/dom-attr-html.dart:21: ret =
elem.$dom_getAttribute('id');
This introduces a significant perf cost and will impact our tests. We should
avoid impacting our benchmarks.

https://codereview.chromium.org/23189014/diff/3001/samples/third_party/dromae...
File samples/third_party/dromaeo/tests/dom-traverse-html.dart (right):

https://codereview.chromium.org/23189014/diff/3001/samples/third_party/dromae...
samples/third_party/dromaeo/tests/dom-traverse-html.dart:37: final nodes =
document.body;
I don't think this is a correct translation.

https://codereview.chromium.org/23189014/diff/3001/tests/html/safe_dom_test.dart
File tests/html/safe_dom_test.dart (right):

https://codereview.chromium.org/23189014/diff/3001/tests/html/safe_dom_test.d...
tests/html/safe_dom_test.dart:73: var range = new Range();
This test requires that the range be created from the other doc. Can we have
that be public?

[Emily Fortuna, 2013-08-27 22:48:43]

ptal

https://codereview.chromium.org/23189014/diff/3001/samples/third_party/dromae...
File samples/third_party/dromaeo/tests/dom-traverse-html.dart (right):

https://codereview.chromium.org/23189014/diff/3001/samples/third_party/dromae...
samples/third_party/dromaeo/tests/dom-traverse-html.dart:37: final nodes =
document.body;
On 2013/08/27 16:08:10, blois wrote:
> I don't think this is a correct translation.

You can index into body to access all of the childNodes just as if you'd
accessed them explicitly. See the diff here:

https://codereview.chromium.org/23189014/diff/3001/sdk/lib/html/dart2js/html_...

-  Node operator[](int index) => _this.$dom_childNodes[index];
+  Node operator[](int index) => _this._childNodes[index];

https://codereview.chromium.org/23189014/diff/3001/tests/html/safe_dom_test.dart
File tests/html/safe_dom_test.dart (right):

https://codereview.chromium.org/23189014/diff/3001/tests/html/safe_dom_test.d...
tests/html/safe_dom_test.dart:73: var range = new Range();
On 2013/08/27 16:08:10, blois wrote:
> This test requires that the range be created from the other doc. Can we have
> that be public?

fixed.

[Emily Fortuna, 2013-08-28 19:17:13]

let's try this again. getAttribute still looks fine performance-wise. I made
childNodes public (the reason I hadn't seen the failure is our perf testing
apparently updates its results incrementally, so I saw there were "traverse"
results, and thought those tests were all complete).

[blois, 2013-08-28 19:22:24]

On 2013/08/28 19:17:13, Emily Fortuna wrote:
> let's try this again. getAttribute still looks fine performance-wise. I made
> childNodes public (the reason I hadn't seen the failure is our perf testing
> apparently updates its results incrementally, so I saw there were "traverse"
> results, and thought those tests were all complete).

Are there perf issues with using Node.nodes instead of Node.childNodes?

[Emily Fortuna, 2013-08-29 22:44:56]

On 2013/08/28 19:22:24, blois wrote:
> On 2013/08/28 19:17:13, Emily Fortuna wrote:
> > let's try this again. getAttribute still looks fine performance-wise. I made
> > childNodes public (the reason I hadn't seen the failure is our perf testing
> > apparently updates its results incrementally, so I saw there were "traverse"
> > results, and thought those tests were all complete).
> 
> Are there perf issues with using Node.nodes instead of Node.childNodes?

I've tested this extensively and I can say with confidence that there are no
perf changes.

[blois, 2013-08-30 00:08:31]

On 2013/08/29 22:44:56, Emily Fortuna wrote:
> On 2013/08/28 19:22:24, blois wrote:
> > On 2013/08/28 19:17:13, Emily Fortuna wrote:
> > > let's try this again. getAttribute still looks fine performance-wise. I
made
> > > childNodes public (the reason I hadn't seen the failure is our perf
testing
> > > apparently updates its results incrementally, so I saw there were
"traverse"
> > > results, and thought those tests were all complete).
> > 
> > Are there perf issues with using Node.nodes instead of Node.childNodes?
> 
> I've tested this extensively and I can say with confidence that there are no
> perf changes.

I'd rather we use Node.nodes rather than exposing Node.childNodes. Unless
there's a performance cost in using Node.nodes.

[blois, 2013-08-30 01:09:28]

lgtm

[Emily Fortuna, 2013-08-30 17:18:53]

Committed patchset #6 manually as r26928 (presubmit successful).