Minor type confusion in proxies proposal?
david.bruant at labri.fr
Fri Jul 1 12:21:22 PDT 2011
Property descriptors as specific "type" is an internal construct of the
ES spec. Their definition in ES5 was used in the context of ES5 (with
normal objects, host objects but no proxies). The proxy API needed a way
to represent them. Objects sound like the natural construct to do so.
First, you have to notice that the object is copied, so a different
object is passed as argument to the defineProperty trap and as argument
within the trap. Same for the return value of getOwnPropertyDescriptor.
So there is no way the proxy can magically change a property descriptor
(since within the proxy, there are only proxies)
Then, the intention behind letting custom attribute pass is to encourage
Proxies have the potential to be arbitrarily complicated; so should be
their "dialog" interface (defineProperty, getOwnPropertyDescriptor). For
instance, in an experiment of mine , I use a custom "index" property
attribute. If some good idea come out (unlike my experiment), they could
be integrated to a next version of ECMAScript.
So I agree that objects as property descriptors within traps instead of
a custom type are a derivation from the spec, but I think it's a good thing.
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)?
 https://github.com/DavidBruant/PropStackObjects (see the HTMLs to
see how it works)
Le 01/07/2011 14:54, Andreas Rossberg a écrit :
> On 1 July 2011 12:12, Andreas Rossberg <rossberg at google.com> wrote:
>> I believe there is some "type" confusion in the proxy proposal spec
>> wrt property descriptors and their reification into attributes
>> 1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal says:
>> "The Desc argument to this trap is a property descriptor object
>> validated by ToPropertyDescriptor, except that it also retains any
>> non-standard attributes present in the original property descriptor
>> passed to Object.defineProperty. See the semantics of the modified
>> Object.defineProperty built-in, below."
>> That seems fishy, since according to ES5 8.10:
>> "Values of the Property Descriptor type are records composed of named
>> fields where each field‘s name is an attribute name and its value is a
>> corresponding attribute value as specified in 8.6.1."
>> In particular, I take this to mean that property descriptors are not
>> objects (but abstract records), and that there cannot be any fields
>> whose name is not an attribute name. (In fact, in V8 we currently
>> encode property descriptors using objects, but the encoding is
>> different from the reified attributes object representation, and not
>> quite compatible with the idea of adding arbitrary other fields.)
> I forgot to say: step 5 of the definition invokes the defineProperty
> trap of the handler passing Desc as the second argument. But the
> handler expects a reified attributes object.
>> 2. In the modified definition of Object.defineProperty, the proposal
>> says in step 4.c:
>> "Call the [[DefineOwnProperty]] internal method of O with arguments
>> name, descObj, and true."
>> This is passing descObj, which in fact is _not_ a descriptor, but its
>> reification as an attributes object.
More information about the es-discuss