[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 #38 from Boris Zbarsky <bzbarsky@mit.edu> ---
> Fixed: https://github.com/heycam/webidl/commit/4de741337480e65c5b36f5bf667dbae421c3f7ac

This forgot to replace "object" by "backing" in the Create*Iterator calls, no?

> Added (at the expense of expanding this section out some more): 

I haven't reviewed this in detail yet; it'll probably happen when we go to
implement it...

> Let me know if you think that looks OK and I'll try with it for setlike/maplike.

It looks pretty good.

The description of where the property lives and its attributes is actually
redundant, since having it in IDL would pin all that down.  Those parts are
only needed for forEach in the maplike/setlike cases, afaict.

> I wonder what the best way to write "create a function one that captures an
> environment with these variables" is.

Hmm.  A bound function?  The problem is that you want to bind the _third_
argument (and the this value) but not the first two args.  :(

I'm not sure what a sane solution is here.  As a UA implementor I can make this
utility function not show up in things like Error stacks and .caller walks, of
course (since I assume it's fundamentally an implementation detail we don't
want to expose), but I'm not sure what the right way to spec this sort of thing
is.

> It's pointing to @@iterator so doesn't need its own behaviour definition. 

Ah, indeed.  I missed that.

> Interested to know what you and other think about this.

I was assuming the requirement that there be an actual backing JS Map/Set was a
conscious design choice.

But yeah, how the UA interacts with that Map/Set is an interesting question. 
It could be done via [[Get]] and [[Call]] equivalents, which would let the page
override methods on it (and e.g. prevent the UA from putting the right things
in it).  It could be done via saved clean copies of the Map/Set methods, or
declaring that the prototype of this Map/Set lives in some clean global; I
think these might be equivalent for sets as long as the Map/Set methods don't
try to [[Get]] on the object... But for things like keys() and values() the
returned iterator would also live in that other global, or something.  Unless
we wrapped it up in our own iterator...

So both those approaches have some fragility and ickiness going on.  I'm not
sure what best to do here.  :(

> I suppose we could treat the backing maps/sets as objects that implement
> callback interfaces, and call them that way?

Yes.  That doesn't address the basic "page can mess with it" issue, of course;
it's just a different way to talk about doing [[Get]] and [[Call]].

Two other comments:

24) What is the point of legacyiterable?  So far the only uses I've seen are in
bug 23212 and look wrong to me.  The way I see it, we need legacyiterable for
cases that (A) don't have indexed getters (or do but want the iterator to
iterate something _other_ than the indexed props) and (B) don't want the extra
methods "iterable" adds.  Are there any such cases?

25) Also as mentioned in bug 23212, it might be nice to have a way to get the
newfangled iterable methods for something with an indexed getter without having
to redefine its iteration behavior like iterable<> forces you to do.  Perhaps
an arrayiterable<> that just adds the methods but keeps %ArrayProto_values% as
the @@iterator?

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

Received on Sunday, 5 October 2014 03:28:44 UTC