fixes #173, ability to use native JS indexers

test/codegen/sunflower/dom.dart

Index: test/codegen/sunflower/dom.dart
diff --git a/test/codegen/sunflower/dom.dart b/test/codegen/sunflower/dom.dart
index e41c7561f8961bb21dd47998dd585a16ddec6f1e..fdbe3764b2e1fba2f92e59e04e217c96a39c8fc7 100644
--- a/test/codegen/sunflower/dom.dart
+++ b/test/codegen/sunflower/dom.dart
@@ -19,6 +19,10 @@ class Overload {
 }
 const overload = const Overload();
 
+class JsIndexer {
+  const JsIndexer();
+}
+
 external Document get document;
 
 @JsName(name: 'Document')
@@ -30,10 +34,27 @@ abstract class Document {
 abstract class Element {
   void addEventListener(String type, EventListener callback, [bool capture]);
   String textContent;
+  NodeList get childNodes;
+}
+
+@JsName()
+class Node {}
+
+@JsName()
+@JsIndexer()

[Jacob, 2015/05/20 19:55:21]

Seems a bit strange to have this annotation on the class. Shouldn't it just be
implied by a
@JsName class with an 
operator []
?

[Jennifer Messerly, 2015/05/20 20:13:30]

Hah, yeah, I wanted it that way too :). But we can't get to that easily because
https://github.com/dart-lang/dev_compiler/issues/132. I could try looking up the
indexer again, essentially "resolve" it from js_codegen, but didn't seem worth
it.

[Jennifer Messerly, 2015/06/01 17:36:58]

Doh, I misunderstood your question.

Restating the Q: why can't @JsName imply @JsIndexable?
A: It could. But we'd have to do something different for JsArray, to indicate it
should *not* be JS-Indexable.

Based on further work in https://codereview.chromium.org/1153003003/, I think we
have a few kinds of JS types.

A. ones like Array, Number, Boolean, String, where we want to pretend they are
entirely Dart types and hide all the JS methods. ("dart:core types")
B. transparent-JS ones, where we want to expose all of the JS methods.
("dart:dom types", or "JS interop types")
C. In the future, we might have types that expose most of JS methods, but add
some Dart extension methods, and maybe subtract some JS methods. ("dart:html
types", "Dartified JS interop types")


Anyway, I'm tempted to say category A uses @JsPeerInterface, category B and C
use @JsName. Then we can have @JsIndexable be implied and remove it. Does that
sound good to you?

+class NodeList {
+  external NodeList();
+  external num get length;
+  external set length(num _);
+  external Node item(num index);
+
+  external Node operator [](num index);
+  external void operator []=(num index, Node);
 }
 
 typedef void EventListener(Event e);
 
+@JsName()
 abstract class Event {}
 
 @JsName(name: 'HTMLInputElement')