- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 10 Apr 2012 16:49:09 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: public-webapps@w3.org
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. >> 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.
Received on Tuesday, 10 April 2012 20:49:39 UTC