Minor type confusion in proxies proposal?

Tom Van Cutsem tomvc.be at gmail.com
Sat Jul 2 06:21:27 PDT 2011


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?

2011/7/2 David Bruant <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>
>
>> 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/04d04ec3/attachment-0001.html>


More information about the es-discuss mailing list