- From: <bugzilla@jessica.w3.org>
- Date: Sun, 05 Oct 2014 03:28:37 +0000
- To: public-script-coord@w3.org
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