fixes #173, ability to use native JS indexers

test/codegen/sunflower/dom.dart

 // Copyright (c) 2015, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 @JsName(name: 'window')
 library dom;
 
 
 class JsName {
   /// The JavaScript name.
   /// Used for classes and libraries.
   /// Note that this could be an expression, e.g. `lib.TypeName` in JS, but it
   /// should be kept simple, as it will be generated directly into the code.
   final String name;
   const JsName({this.name});
 }
 class Overload {
   const Overload();
 }
 const overload = const Overload();
 
+class JsIndexer {
+  const JsIndexer();
+}
+
 external Document get document;
 
 @JsName(name: 'Document')
 abstract class Document {
   Element querySelector(String selector);
 }
 
 @JsName(name: 'Element')
 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')
 abstract class InputElement extends Element {
   String value;
 }
 
 @JsName(name: 'HTMLCanvasElement')
 abstract class CanvasElement extends Element {
   RenderingContext getContext(String contextId);
@@ skipping 135 matching lines @@
 abstract class TextMetrics {
   num get width;
 }
 
 @JsName()
 abstract class ImageData {
   int get width;
   int get height;
   // TODO: readonly Uint8ClampedArray data;
 }