Minor type confusion in proxies proposal?

David Bruant david.bruant at labri.fr
Sat Jul 2 06:43:10 PDT 2011


Le 02/07/2011 15:21, Tom Van Cutsem a écrit :
> You're right, including inherited attributes would be more consistent
> with the current ES5 behavior.
>
> Since the proxy needs to "loop over" the properties of the property
> descriptor object, what better abstraction to mimic than the for-in
> loop? I.e. it is probably easiest for programmers to figure out what's
> going on if proxies detect custom attributes by doing:
>
> for (var attr in propertyDescriptorObject) {
>   ... // copy all non-standard attributes into a fresh property
> descriptor object
> }
>
> That is: custom attributes are all own or inherited, enumerable
> property names of the property descriptor object, and overridden
> attribute values get priority over inherited attribute values.
>
> Does that sound right?
So the set of attributes would be the union of standard attributes
(regardless of enumerability) and properties retrieved through for-in if
I understand well.
It sounds like if the standard attribute set changes over time, code
could break, but it also looks like an intricable problem, so I think
that this is the best trade-off.

David
>
> 2011/7/2 David Bruant <david.bruant at labri.fr
> <mailto:david.bruant at labri.fr>>
>
>     Le 02/07/2011 13:53, Tom Van Cutsem a écrit :
>>     2011/7/1 David Bruant <david.bruant at labri.fr
>>     <mailto:david.bruant at labri.fr>>
>>
>>         Tom: about "...except that it also retains any non-standard
>>         attributes
>>         present in the original property descriptor passed to
>>         Object.defineProperty.", what do you mean by "any"?
>>         Is it Object.keys(desc)?
>>         Object.enumerate(desc) (I mean the prop list enumerated over
>>         with for-in)?
>>         Object.getOwnPropertyNames(desc)?
>>
>>
>>     I meant any own properties of the argument, regardless of
>>     enumerability (i.e. as determined by Object.getOwnPropertyNames).
>>     This is consistent with the modifications to
>>     Object.defineProperty, step 4.b.
>     Actually, in ES5 the ToPropertyDescriptor function (8.10.5) (used
>     in the original Object.defineProperty step 3 (and your version
>     too)) calls [[HasProperty]] and [[Get]] on the object expected to
>     become a property descriptor, meaning that the prototype is climbed.
>     -----
>     // Currently, for ToPropertyDescriptor (and Object.defineProperty
>     as a consequence),
>
>     null <| {enumerable:true, configurable:false} <| {set:
>     function(){}, get:function(){}}
>
>     // is equivalent to
>
>     {set: function(){}, get:function(){}, enumerable:true,
>     configurable:false}
>
>     // because it calls [[HasProperty]] and [[Get]]
>     // Sorry for the harmony:proto_operator notation abuse. I'm not
>     sure I can chain it.
>     -----
>
>     I'm afraid that if we do not climb the prototype at all now, there
>     might be inconsistencies if later the spec standardized custom
>     attributes.
>     In the case of a custom attribute is put in the prototype now, it
>     won't be passed to a proxy, while it will whenever this attribute
>     becomes part of a later version of the standard (because I assume
>     that for consistency sake, [[HasProperty]] and [[Get]] will be
>     used too to retrieve it).
>     This may create complicated bugs to notice. (think about a trap
>     looping over property descriptor attributes. standardizing more
>     attribute could change the number of attributes looped over)
>
>     I would recommand to climb the prototype to detect custom
>     attributes since that's what the ToPropertyDescriptor algorithm
>     does. Of course, passing every single property is stupid since it
>     would pass things like 'hasOwnProperty' (retrieved from
>     Object.prototype), hence the idea of filtering out non-enumerable
>     properties.
>     Maybe the set of properties passed to the trap could be the union
>     of Object.getOwnPropertyNames and Object.enumerate (for-in loops)?
>
>     Maybe it's already time to add a custom property descriptor like
>     "notAPropertyAttribute" (defauting to false, sorry for double
>     negation)?
>
>     Another alternative is changing ToPropertyDescriptor, but I think
>     it's too late now.
>
>     David
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110702/ed7e4383/attachment.html>


More information about the es-discuss mailing list