Minor type confusion in proxies proposal?

David Bruant david.bruant at labri.fr
Sat Jul 2 05:29:45 PDT 2011


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/93fa6ab3/attachment.html>


More information about the es-discuss mailing list