- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 10 Apr 2012 14:05:01 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-webapps@w3.org
On Tue, Apr 10, 2012 at 1:49 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 4/10/12 4:23 PM, Tab Atkins Jr. wrote: >> On Tue, Apr 10, 2012 at 1:16 PM, Boris Zbarsky<bzbarsky@mit.edu> wrote: >>> On 4/10/12 4:13 PM, Tab Atkins Jr. wrote: >>>> According to current WebIDL spec, an object with a named property >>>> getter exposes the list of names as own properties, so you can get >>>> them with for-in enumeration. >>> >>> >>> 1) for-in enumeration enumerates prototype properties. >> >> >> Yes, but prototype properties aren't own properties, so you can tell them >> apart. > > > Yes, but it's a huge pain that no one will actually remember to do. > > I didn't say there is _no_ way to enumerate the objects. I said there is no > _good_ way. There's a difference. If you expect people to commonly need to > enumerate the set of named flows, then there is something to be said for > making it easy and safe, not hard and footgunny. Agreed, but ES6 is making this easier with Object.keys() and for-of iteration. (Off the top of my head, I can't come up with a use-case for enumerating all flows in a page anyway, beyond editing environments or the like.) >>> 2) for-in enumeration enumerates expandos which might have nothing to >>> do with the set of named properties. >> >> It's not possible to set an expando on a map object like this. (The >> setter operation will either do something useful, or will reject the >> attempt to set.) > > The setter for interfaces that support named properties is not applied to > things outside the set of supported property names per current WebIDL [1]. > So if the set of supported property names here is the set of flow names, > then expandos with other names can be defined. The proposal on this list > didn't actually say what the set of supported property names is, but the > proposal at http://lists.w3.org/Archives/Public/www-style/2012Feb/0327.html > does say that the supported property names are the flow names. > > -Boris > > [1] Specifically, http://dev.w3.org/2006/webapi/WebIDL/#defineownproperty > step 3 is where we would end up. If the name is not a supported property > name, 'creating' is set true in step 3.1. We enter step 3.2, because we do > not have a property named P. Since 'creating' is true, we skip step 3.2.1. > Since 'creating' is false and there is no named property creator, we skip > step 3.2.2. So we end up in step 4, which just does a completely normal JS > property set on the object; now we have an "expando" property. Sorry, I misspoke. You do indeed need to define a named property creator, which either does something useful or just rejects the creation. ~TJ
Received on Tuesday, 10 April 2012 21:05:51 UTC