Minor type confusion in proxies proposal?

Mark S. Miller erights at google.com
Sun Jul 3 10:00:07 PDT 2011


On Sun, Jul 3, 2011 at 4:29 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:

> Hi Andreas,
>
> Bypassing [[DefineOwnProperty]] in Object.defineProperty for proxies could
> work. It would also totally bypass the question of how non-standard
> attributes are identified or need to be copied, as the property descriptor
> argument to Object.defineProperty can be passed directly to the trap. Mark:
> would this introduce any security concerns? One potential issue I see is
> that standard attributes may be defined as accessor rather than data
> properties, which means they can report different values over time.
>

Yes. I'm not against a pass through, but only if, for the standard
attributes (or possibly all) we do all the value-to-value protective copying
of the current system. The descriptor object given to the trap should have
only data properties, at least for the properties representing standard
attributes.



>
> Here is a possible revised semantics for [[DefineOwnProperty]] on trapping
> proxies, and the Object.defineProperty built-in:
>
> [[DefineOwnProperty]] (P, Desc, Throw)
>
> When the [[DefineOwnProperty]] internal method of a trapping proxy O is
> called with property name P, property descriptor Desc and Boolean flag
> Throw, the following steps are taken:
>
> 1. Let descObj be FromGenericPropertyDescriptor(Desc) // see
> harmony:proxies_semantics page
> 2. Return DefineProxyProperty(O, P, descObj, Throw)
>
> DefineProxyProperty (Proxy, P, DescObj, Throw)
>
> When the DefineProxyProperty auxiliary function is called with a trapping
> proxy Proxy, a property name P, an Object DescObj and a Boolean flag Throw,
> the following steps are taken:
>
> 1. Let handler be the value of the [[Handler]] internal property of Proxy.
> 2. Let defineProperty be the result of calling the [[Get]] internal method
> of handler with argument “defineProperty”.
> 3. If defineProperty is undefined, throw a TypeError exception.
> 4. If IsCallable(defineProperty) is false, throw a TypeError exception.
> 5. Let trapResult be the result of calling the [[Call]] internal method of
> defineProperty providing handler as the this value, P as the first argument
> and DescObj as the second argument.
>

This pass-through without protective copying is too hazardous. It means each
handler must individually protect itself, not only against accessor
behavior, but against the caller changing the shared DescObj after the fact.



> 6. Let success be ToBoolean(trapResult)
> 7. If success is false, reject
> 8. Return true
>
> Object.defineProperty (O, P, Attributes)
>
> 1. If Type(O) is not Object throw a TypeError exception.
> 2. Let name be ToString(P).
> 3. If O is a trapping proxy
>   a. Call DefineProxyProperty(O, name, Attributes, true)
>   b. Return O.
> 4. Let desc be the result of ToPropertyDescriptor(Attributes)
> 5. Call the [[DefineOwnProperty]] internal method of O with arguments name,
> desc, and true.
> 6. Return O.
>
> Comments?
>
> 2011/7/2 Andreas Rossberg <rossberg at google.com>
>
>> Hi Tom.
>>
>> On 2 July 2011 13:50, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> > Hi Andreas,
>> > First, you're right about the typing issue:
>> > In ES5, for values of type Object, the signature for
>> [[DefineOwnProperty]]
>> > would be:
>> > [[DefineOwnProperty]](P: a property name, Desc: an internal property
>> > descriptor, Throw: a boolean)
>> > On trapping proxies, that signature would need to change to:
>> > [[DefineOwnProperty]](P: a property name, Desc: an Object, Throw: a
>> boolean)
>>
>> I don't think such a change is consistent. [[DefineOwnProperty]] is
>> invoked in a number of places in the spec, and I think in many of them
>> the type of the receiver is not distinguished and may well be a proxy,
>> so a proxy may then receive both kinds of descriptors. Moreover, I
>> think it would be a mistake to make the appropriate case distinction
>> everywhere -- you really want the internal method to have the same
>> signature in all cases.
>>
>> > With that, I believe the strawman is otherwise internally consistent. In
>> > [[DefineOwnProperty]] step 5, what will be passed to the user-defined
>> > "defineProperty" trap is a proper Object, not an internal descriptor.
>> > I did clarify the note you referred to, to be more explicit in this
>> regard.
>> > I don't see an alternative to changing the signature of
>> > [[DefineOwnProperty]]. It can't just receive an internal descriptor, as
>> it
>> > doesn't preserve any non-standard attributes.
>>
>> How about simply bypassing [[DefineOwnProperty]] in
>> Object.defineProperty for proxies, as I suggested in my reply to
>> David? That seems to be the only place where additional objects can
>> occur, or am I wrong?
>>
>> Cheers,
>> /Andreas
>>
>>
>> > 2011/7/1 Andreas Rossberg <rossberg at google.com>
>> >>
>> >> 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
>> >> > objects.
>> >> >
>> >> > 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.
>> >> >
>> >> > /Andreas
>> >> >
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> es-discuss at mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110703/635338d3/attachment.html>


More information about the es-discuss mailing list