Re: [DOM4] Question about collections versus maps

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