[Bug 26183] make it easier to define an iterator on an interface that iterates over a set of values

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26183

--- Comment #35 from Boris Zbarsky <bzbarsky@mit.edu> ---
1) In http://heycam.github.io/webidl/#es-iterators, this bit:

  If the interface does not have an iterator 

should probably be:

  If the interface does not have an iterable declaration

?

2) For the indexed case, why can we not just say that the value of @@iterator
is literally the initial value of Array.prototype[@@iterator] (which is
%ArrayProto_values% as it happens)?  I see no particular need to enforce
belonging to the right interface, or do security check bits here; none of that
stuff is needed for sanity in this case imo.

3) For the maplike/setlike cases, I guess we can't just have @@iterator point
to the same object as Map.prototype[@@iterator] and Set.prototype.[@@iterator]
because those do the branding checks Domenic points out?  That would have
avoided having the bug where "value" should probably be "key+value" for the Map
to match how ES Map behaves.  :(

4) In the forEach steps for iterable declarations, why not make sure callbackFn
is callable before getting "values"?  In fact, why not define the property
location, as well as current steps 1-4 and 7-8 of its behavior by just saying
that it should act as if the interface had:

  void forEach(Function callback, optional any thisArg = undefined);

at the end of its IDL?  That would also allow you to defer to the invoke a
callback steps for parts of step 11, and remove the necessity for step 12, I
think (because now you'd only be specifying prose for an IDL function, not the
whole thing from start to finish).

5)  For the forEach for setlike/maplike bits, seems you could do something
similar.

6)  For the setlike/maplike forEach, is a new callbackWrapper created on each
forEach call, or is one created then reused?  I believe this is page-detectable
via examining the stack...

7)  For the setlike/maplike forEach, we should be consistent about whether the
third arg of callbackWrapper is "o" or "object".

8)  Is the callbackWrapper anything more than callbackFn.bind(thisArg)
(assuming a new one is created every time and that we're talking canonical bind
here)?  If so, is it worth making that clearer?

9)  By the time I got to "entries" I was getting tired of the copy/pasted "The
location of the property is determined as follows" bit.  Could we refactor that
into a definition or something.

10) "declared use" should be "declared using".

11) The section on "values" has the wrong property name, and no definition of
the behavior the function should have.

12) The link to "iterator" in the first paragraph of the "Iterator prototype
object" section is broken.

13) I don't follow step 4 of "forwards to the internal map object".  Where is
"this Function that implements the size property" coming from there? 
Copy/paste error?

14) In "forwards to the internal map object" after step 7 need to check whether
"function" is callable, right?

15) Looks like the idea is that the implementation can interpose some sort of
logic of its own for clear/set/delete but not for entries/get/has/keys/values,
right?  This does mean that the [[BackingMap]] can't be lazily
computed/updated, correct?

16) Is [MapClass] still a thing?  "Maplike declarations" paragraph 2 makes it
sound like it is, but I assume that should say "maplike declaration"?

17) Similarly "Setlike declarations" paragraph 2 should not talk about
"[SetClass]", I assume.

18) "forwards to the internal set object" step 4 looks like it also has a
copy/paste issue.

19) "forwards to the internal set object" after step 7 need to check that
"function" is callable.

20) Iterator prototypes should have a method named @@iterator on them that
returns the "this" value.  See what %ArrayIteratorPrototype%[@@iterator] does
in ES6.  

21) We need to define what the .name is for these @@iterator functions. 
Actually, for all Functions in Web IDL, now that it looks like .name is an ES6
thing.  But we can reuse the "Unless otherwise specified, this value is the
name that is given to the function in this specification..." language ES6 has
for most cases; just not this case.

22) I think Domenic is right that actual type-enforcement is totally missing
here for the mutator methods when those are not otherwise specified.  Again, I
think it would be good to define behavior here in terms of things acting as if
they were effectively added to the IDL, which would get you the "this"-checks
for free, and argument coercions to the right types for free...  Would require
a bit of finagling to, e.g., wrap up the "function" being called through to
into an IDL Function.  Or conversions back from IDL to ES values before doing
the [[Call]].  Or some such.

23) The backing map and set are just chaining up to their proto, right?  So if
someone changes Set.prototype.entries that will change the behavior of
.entries() on all setlikes?  That's pretty nice!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Saturday, 4 October 2014 05:41:44 UTC