W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [DOM4] Question about collections versus maps

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 10 Apr 2012 16:49:09 -0400
Message-ID: <4F849CC5.5060603@mit.edu>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:51 GMT