Array-like types in the DOM do not support index access

[vsmenon]

When we access raw JS versions of Array-like or Dictionary-like types - NodeList, NamedNodeMap, DOMTokenList - we hit an error:

NodeList list = querySelectorAll(query);
list[0];

DDC generates list.get(0) for the above - which does not exist for these types.

@jacob314

[jmesserly]

#138 might help here. But not sure if we consider indexer methods as extension ones or not.

[jmesserly]

what's going wrong here is a bit complex, here's some thoughts.

First off, static dispatch. We never generate [] at the moment for JS indexable (native) types. I think it was just never implemented. Arrays work because they have an extension method for [] and []= (it does bounds checking), so we did not have to add this feature for them.

Here's how NodeList is defined (warning, big file: dom.dart#L10158)

@JsName()
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);
}

if we statically know it's a native [] operator, two options:

• inject an extension method that does bounds checking (needs length getter)
• just call the indexer as you would in JS

I'd lean towards the latter. Compiler shouldn't make up a bounds check function without user asking for it. That said, we could make something that a type can opt-in to, and perhaps use that in dart:html but not dart:dom. (Also extension methods will only work if it's a nominal type in JS, else we can't reliably extend all instances.)

[jmesserly]

Another wrinkle: for the dart:core types, we want to assume that all methods will be Dart defined, and native methods are all hidden from dynamic dispatch. That is, extension methods are all or nothing as we currently use them. For dart:html types, I presume we want most native methods to appear, some hidden, and some extensions? That will make things a little more complicated. We can probably make it work though

[jmesserly]

https://codereview.chromium.org/1145833004/ makes it possible to define native JS indexers on the @JsName() type

[jmesserly]

I'm going to wait for the fix big #138 patch (https://codereview.chromium.org/1153003003/) to land and then take another look here.

[jmesserly]

rebased against that fix, should be good to go