[Harmony Proxies] Proposal: Property fixing

classic Classic list List threaded Threaded
140 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Mark S. Miller-2


On Wed, May 18, 2011 at 7:38 AM, Brendan Eich <[hidden email]> wrote:
On May 18, 2011, at 7:28 AM, Tom Van Cutsem wrote:

> Proxies do coerce all property names to strings, e.g. proxy[obj] will trigger the 'get' trap with 'obj' coerced to a String. This is not actually enforced by the proxy spec, but rather by ES5 (e.g. [[Get]] assumes that its argument P is bound to a property name (a String)). At one point we suggested removing this restriction, so that "proxy[obj]" would give the get trap direct access to obj (which would be particularly useful when intercepting numeric indices on array-like proxies). IIRC, we didn't pursue this option since engines rely on property names being strings in other places, and widening the type of property names to cover arbitrary objects would be problematic.

SpiderMonkey has a wider internal property name type, which can accomodate at least int and object names. The int case is an optimization, commonly done. The object case is for E4X and perhaps private names.

Oliver wrote in the thread at the time that he thought allowing any value to be used as a property name (in brackets) and passed through uncoerced to proxies was implementable without trouble for JavaScriptCore, IIRC.

That's the opposite of my memory, but it was a long time ago. Oliver?

 

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Brendan Eich-3
On May 18, 2011, at 7:45 AM, Mark S. Miller wrote:

On Wed, May 18, 2011 at 7:38 AM, Brendan Eich <[hidden email]> wrote:
On May 18, 2011, at 7:28 AM, Tom Van Cutsem wrote:

> Proxies do coerce all property names to strings, e.g. proxy[obj] will trigger the 'get' trap with 'obj' coerced to a String. This is not actually enforced by the proxy spec, but rather by ES5 (e.g. [[Get]] assumes that its argument P is bound to a property name (a String)). At one point we suggested removing this restriction, so that "proxy[obj]" would give the get trap direct access to obj (which would be particularly useful when intercepting numeric indices on array-like proxies). IIRC, we didn't pursue this option since engines rely on property names being strings in other places, and widening the type of property names to cover arbitrary objects would be problematic.

SpiderMonkey has a wider internal property name type, which can accomodate at least int and object names. The int case is an optimization, commonly done. The object case is for E4X and perhaps private names.

Oliver wrote in the thread at the time that he thought allowing any value to be used as a property name (in brackets) and passed through uncoerced to proxies was implementable without trouble for JavaScriptCore, IIRC.

That's the opposite of my memory, but it was a long time ago. 

I was thinking of


at least. Probably some IRC convo after that as well, but at least that.

/be


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Mark S. Miller-2
On Wed, May 18, 2011 at 8:50 AM, Brendan Eich <[hidden email]> wrote:
On May 18, 2011, at 7:45 AM, Mark S. Miller wrote:
[...] 
Oliver wrote in the thread at the time that he thought allowing any value to be used as a property name (in brackets) and passed through uncoerced to proxies was implementable without trouble for JavaScriptCore, IIRC.

That's the opposite of my memory, but it was a long time ago. 

I was thinking of


at least. Probably some IRC convo after that as well, but at least that.

I stand corrected. Thanks for the clarification.


--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Oliver Hunt-2
In reply to this post by Mark S. Miller-2
IIRC I was saying that the engine should simply allow non-objects types to pass through uncoerced, rather than taking any particular stance on ease of implementation.  I suspect in JSC that we would be able to do it without too much difficulty, but there's a a world of difference between that, and it actually being the case.

--Oliver

On May 18, 2011, at 7:45 AM, Mark S. Miller wrote:



On Wed, May 18, 2011 at 7:38 AM, Brendan Eich <[hidden email]> wrote:
On May 18, 2011, at 7:28 AM, Tom Van Cutsem wrote:

> Proxies do coerce all property names to strings, e.g. proxy[obj] will trigger the 'get' trap with 'obj' coerced to a String. This is not actually enforced by the proxy spec, but rather by ES5 (e.g. [[Get]] assumes that its argument P is bound to a property name (a String)). At one point we suggested removing this restriction, so that "proxy[obj]" would give the get trap direct access to obj (which would be particularly useful when intercepting numeric indices on array-like proxies). IIRC, we didn't pursue this option since engines rely on property names being strings in other places, and widening the type of property names to cover arbitrary objects would be problematic.

SpiderMonkey has a wider internal property name type, which can accomodate at least int and object names. The int case is an optimization, commonly done. The object case is for E4X and perhaps private names.

Oliver wrote in the thread at the time that he thought allowing any value to be used as a property name (in brackets) and passed through uncoerced to proxies was implementable without trouble for JavaScriptCore, IIRC.

That's the opposite of my memory, but it was a long time ago. Oliver?

 

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem-3
In reply to this post by seaneagan1
Hi,

To address the outstanding issue of how proxies should deal with non-configurable properties, I picked up on Sean's earlier proposal, adapted it and turned it into a strawman: <http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties>.

My adaptation is more permissive than the original proposal in that it still allows proxies to intercept access to non-configurable properties if they are willing to expose them as accessor rather than data properties.

This proposal would allow proxies to cover more use cases (because they can now emulate non-configurable properties), at the expense of additional complexity within proxy objects.

As always, discussion and feedback are appreciated.

Cheers,
Tom

2011/5/4 Sean Eagan <[hidden email]>
What:

Honor attempts to make individual proxy properties non-configurable.

Why:

For consistency since attempts to make *all* of a proxy's properties
non-configurable are honored via the "fix" trap.

Example:

var x = Proxy.create({
 defineProperty: function() {},
 getPropertyDescriptor: function() {
   return {
     value: "whatever I want",
     writable: true,
     configurable: true,
     enumerable: false
   };
 }
});
Object.defineProperty(x, "foo", {value: "bar", configurable: false,
writable: false, enumerable: true};

/* ... */

// logs "whatever I want", not "bar"
console.log(x.foo);
// non-writable, but doesn't throw
object.foo = "baz";
// non-configurable, but doesn't throw
Object.defineProperty(x, "foo", {configurable: true});

How:

Assume a "defineProperty" trap invocation due to
|Object.defineProperty(proxy, name, pd)| where |!pd.configurable|.  If
return value is...

 true - Henceforth bypass |proxy|'s handler for any traps with a
property name parameter when the property name would be |name|
 false - throw TypeError similarly to "fix" trap

Update the "fix" trap semantics such that when its return value is not
undefined but rather a property descriptor map, behavior is similar to
|Object.defineProperties| in that improperly redefining any properties
will cause a TypeError to be thrown.

Notes:

Can check |Object.getOwnPropertyDescriptor(proxy, name).configurable|
to determine if a given proxy property is fixed since it will always
be false in this case.


Thanks,
Sean Eagan
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Allen Wirfs-Brock
Doesn't this new proposal still preclude using proxies to create an exact emulation of the built-in Array object type.  The "length" property of arrays is specified to be non-configurable yet special behavior must occur each time the value of length is changed.  The proposal would allow "length" to be "fixed"  as an accessor property whose set behavior did the necessary processing.  However, that is also a violation of the Array specification as it requires that "length" exhibit the attributes of a data property. 

I emphasize Array when I look at this simply because it is a fairly simple example of the sort of thing that a host object might currently do and the most important use case of proxies for me is the replacement/emulation of host objects.  I really don't know where this idea that non-configurable implies no special semantics comes from.  That isn't the case in the ES5 specification  (10.6,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such properties.  

Allen




On Jun 14, 2011, at 1:57 AM, Tom Van Cutsem wrote:

Hi,

To address the outstanding issue of how proxies should deal with non-configurable properties, I picked up on Sean's earlier proposal, adapted it and turned it into a strawman: <http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties>.

My adaptation is more permissive than the original proposal in that it still allows proxies to intercept access to non-configurable properties if they are willing to expose them as accessor rather than data properties.

This proposal would allow proxies to cover more use cases (because they can now emulate non-configurable properties), at the expense of additional complexity within proxy objects.

As always, discussion and feedback are appreciated.

Cheers,
Tom

2011/5/4 Sean Eagan <[hidden email]>
What:

Honor attempts to make individual proxy properties non-configurable.

Why:

For consistency since attempts to make *all* of a proxy's properties
non-configurable are honored via the "fix" trap.

Example:

var x = Proxy.create({
 defineProperty: function() {},
 getPropertyDescriptor: function() {
   return {
     value: "whatever I want",
     writable: true,
     configurable: true,
     enumerable: false
   };
 }
});
Object.defineProperty(x, "foo", {value: "bar", configurable: false,
writable: false, enumerable: true};

/* ... */

// logs "whatever I want", not "bar"
console.log(x.foo);
// non-writable, but doesn't throw
object.foo = "baz";
// non-configurable, but doesn't throw
Object.defineProperty(x, "foo", {configurable: true});

How:

Assume a "defineProperty" trap invocation due to
|Object.defineProperty(proxy, name, pd)| where |!pd.configurable|.  If
return value is...

 true - Henceforth bypass |proxy|'s handler for any traps with a
property name parameter when the property name would be |name|
 false - throw TypeError similarly to "fix" trap

Update the "fix" trap semantics such that when its return value is not
undefined but rather a property descriptor map, behavior is similar to
|Object.defineProperties| in that improperly redefining any properties
will cause a TypeError to be thrown.

Notes:

Can check |Object.getOwnPropertyDescriptor(proxy, name).configurable|
to determine if a given proxy property is fixed since it will always
be false in this case.


Thanks,
Sean Eagan
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

seaneagan1
Hi Allen,

I believe the best way to enable emulation of each builtin type would
be to orthogonalize the proxy semantics, such that proxies are no
longer a separate language type, but rather an internal capability
accessible to all object types.  This for example would allow for
creation of array proxies whose internal [[DefineOwnProperty]]
internal property is 15.4.5.1 just as with regular arrays, where
8.12.9 is updated with "defineProperty" trapping semantics, so the
"defineProperty" trap would be invoked for both the "length" property
and the array index property on calls to the array proxy's
[[DefineOwnProperty]] internal method.  It might additionally be
useful to allow proxies to override the entirety of 15.4.5.1, in which
case there could be a "defineArrayProperty" trap for this purpose.
The same thing idea would be used to allow proxies to emulate 10.6,
15.3.5.4, 15.5.5.2.  As in
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014838.html
these default behaviors would just be the existing prose rather than
duplicate ES-defined default trap implementations.

A possible API for such an orthogonalized proxy semantics might be
"object descriptors" an object level equivalent to property
descriptors, where one of the object level attributes is "handler" (
[[Handler]] ).  I am working on a formal proposal which includes all
of these concepts, hope to get it out soon.

Would this alleviate some of your concerns with the "fixed properties" proposal?

On Tue, Jun 14, 2011 at 11:56 AM, Allen Wirfs-Brock
<[hidden email]> wrote:

> Doesn't this new proposal still preclude using proxies to create an exact
> emulation of the built-in Array object type.  The "length" property of
> arrays is specified to be non-configurable yet special behavior must occur
> each time the value of length is changed.  The proposal would allow "length"
> to be "fixed"  as an accessor property whose set behavior did the necessary
> processing.  However, that is also a violation of the Array specification as
> it requires that "length" exhibit the attributes of a data property.
> I emphasize Array when I look at this simply because it is a fairly simple
> example of the sort of thing that a host object might currently do and the
> most important use case of proxies for me is the replacement/emulation of
> host objects.  I really don't know where this idea that non-configurable
> implies no special semantics comes from.  That isn't the case in the ES5
> specification  (10.6,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such
> properties.
> Allen
>
>
>
> On Jun 14, 2011, at 1:57 AM, Tom Van Cutsem wrote:
>
> Hi,
> To address the outstanding issue of how proxies should deal with
> non-configurable properties, I picked up on Sean's earlier proposal, adapted
> it and turned it into a strawman:
> <http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties>.
> My adaptation is more permissive than the original proposal in that it still
> allows proxies to intercept access to non-configurable properties if they
> are willing to expose them as accessor rather than data properties.
> This proposal would allow proxies to cover more use cases (because they can
> now emulate non-configurable properties), at the expense of additional
> complexity within proxy objects.
> As always, discussion and feedback are appreciated.
> Cheers,
> Tom
> 2011/5/4 Sean Eagan <[hidden email]>
>>
>> What:
>>
>> Honor attempts to make individual proxy properties non-configurable.
>>
>> Why:
>>
>> For consistency since attempts to make *all* of a proxy's properties
>> non-configurable are honored via the "fix" trap.
>>
>> Example:
>>
>> var x = Proxy.create({
>>  defineProperty: function() {},
>>  getPropertyDescriptor: function() {
>>    return {
>>      value: "whatever I want",
>>      writable: true,
>>      configurable: true,
>>      enumerable: false
>>    };
>>  }
>> });
>> Object.defineProperty(x, "foo", {value: "bar", configurable: false,
>> writable: false, enumerable: true};
>>
>> /* ... */
>>
>> // logs "whatever I want", not "bar"
>> console.log(x.foo);
>> // non-writable, but doesn't throw
>> object.foo = "baz";
>> // non-configurable, but doesn't throw
>> Object.defineProperty(x, "foo", {configurable: true});
>>
>> How:
>>
>> Assume a "defineProperty" trap invocation due to
>> |Object.defineProperty(proxy, name, pd)| where |!pd.configurable|.  If
>> return value is...
>>
>>  true - Henceforth bypass |proxy|'s handler for any traps with a
>> property name parameter when the property name would be |name|
>>  false - throw TypeError similarly to "fix" trap
>>
>> Update the "fix" trap semantics such that when its return value is not
>> undefined but rather a property descriptor map, behavior is similar to
>> |Object.defineProperties| in that improperly redefining any properties
>> will cause a TypeError to be thrown.
>>
>> Notes:
>>
>> Can check |Object.getOwnPropertyDescriptor(proxy, name).configurable|
>> to determine if a given proxy property is fixed since it will always
>> be false in this case.
>>
>>
>> Thanks,
>> Sean Eagan
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>



--
Sean Eagan
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem-3
In reply to this post by Allen Wirfs-Brock
2011/6/14 Allen Wirfs-Brock <[hidden email]>
Doesn't this new proposal still preclude using proxies to create an exact emulation of the built-in Array object type.  The "length" property of arrays is specified to be non-configurable yet special behavior must occur each time the value of length is changed.  The proposal would allow "length" to be "fixed"  as an accessor property whose set behavior did the necessary processing.  However, that is also a violation of the Array specification as it requires that "length" exhibit the attributes of a data property. 

It is true that this strawman would not enable a faithful emulation of the Array "length" property at the meta-level (i.e. when looking at an object as a set of property descriptors). I can't yet judge how much of an issue this is: given the novelty of the property descriptor API, I don't know how much code such an imperfect Array proxy would break. At least at the "base-level" (i.e. regular application code), "length" would be updated as expected, and remains accessible as "arrayproxy.length".

(As an aside: re. the emulation of arrays, having a configurable [[Class]] such that |Object.prototype.toString.call(arrayproxy)| can return "[object Array]" seems like a more important imperfection to fix)
 
I emphasize Array when I look at this simply because it is a fairly simple example of the sort of thing that a host object might currently do and the most important use case of proxies for me is the replacement/emulation of host objects.  I really don't know where this idea that non-configurable implies no special semantics comes from.  That isn't the case in the ES5 specification  (10.6,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such properties.

I'm not sure what you mean by special semantics. If you mean strong guarantees/invariants, then one example would be that a non-writable, non-configurable data property is guaranteed to have a stable value. The proposed strawman allows proxies to define such properties, at the expense of giving up interception of access to such a property.

Cheers,
Tom
 
Allen




On Jun 14, 2011, at 1:57 AM, Tom Van Cutsem wrote:

Hi,

To address the outstanding issue of how proxies should deal with non-configurable properties, I picked up on Sean's earlier proposal, adapted it and turned it into a strawman: <http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties>.

My adaptation is more permissive than the original proposal in that it still allows proxies to intercept access to non-configurable properties if they are willing to expose them as accessor rather than data properties.

This proposal would allow proxies to cover more use cases (because they can now emulate non-configurable properties), at the expense of additional complexity within proxy objects.

As always, discussion and feedback are appreciated.

Cheers,
Tom

2011/5/4 Sean Eagan <[hidden email]>
What:

Honor attempts to make individual proxy properties non-configurable.

Why:

For consistency since attempts to make *all* of a proxy's properties
non-configurable are honored via the "fix" trap.

Example:

var x = Proxy.create({
 defineProperty: function() {},
 getPropertyDescriptor: function() {
   return {
     value: "whatever I want",
     writable: true,
     configurable: true,
     enumerable: false
   };
 }
});
Object.defineProperty(x, "foo", {value: "bar", configurable: false,
writable: false, enumerable: true};

/* ... */

// logs "whatever I want", not "bar"
console.log(x.foo);
// non-writable, but doesn't throw
object.foo = "baz";
// non-configurable, but doesn't throw
Object.defineProperty(x, "foo", {configurable: true});

How:

Assume a "defineProperty" trap invocation due to
|Object.defineProperty(proxy, name, pd)| where |!pd.configurable|.  If
return value is...

 true - Henceforth bypass |proxy|'s handler for any traps with a
property name parameter when the property name would be |name|
 false - throw TypeError similarly to "fix" trap

Update the "fix" trap semantics such that when its return value is not
undefined but rather a property descriptor map, behavior is similar to
|Object.defineProperties| in that improperly redefining any properties
will cause a TypeError to be thrown.

Notes:

Can check |Object.getOwnPropertyDescriptor(proxy, name).configurable|
to determine if a given proxy property is fixed since it will always
be false in this case.


Thanks,
Sean Eagan
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

David Bruant-4
Le 15/06/2011 13:34, Tom Van Cutsem a écrit :
2011/6/14 Allen Wirfs-Brock <[hidden email]>
Doesn't this new proposal still preclude using proxies to create an exact emulation of the built-in Array object type.  The "length" property of arrays is specified to be non-configurable yet special behavior must occur each time the value of length is changed.  The proposal would allow "length" to be "fixed"  as an accessor property whose set behavior did the necessary processing.  However, that is also a violation of the Array specification as it requires that "length" exhibit the attributes of a data property. 

It is true that this strawman would not enable a faithful emulation of the Array "length" property at the meta-level (i.e. when looking at an object as a set of property descriptors). I can't yet judge how much of an issue this is: given the novelty of the property descriptor API, I don't know how much code such an imperfect Array proxy would break. At least at the "base-level" (i.e. regular application code), "length" would be updated as expected, and remains accessible as "arrayproxy.length".

(As an aside: re. the emulation of arrays, having a configurable [[Class]] such that |Object.prototype.toString.call(arrayproxy)| can return "[object Array]" seems like a more important imperfection to fix)
I disagree. People can fix this one by themselves: https://gist.github.com/1026960 (I haven't tested, but it gives the idea). Of course this solution is valid as long as observable side effects of [[Class]] can be redefined.
This is not the case for the .length issue.

Cheers,

David

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Brendan Eich-3
On Jun 15, 2011, at 5:19 AM, David Bruant wrote:

Le 15/06/2011 13:34, Tom Van Cutsem a écrit :
(As an aside: re. the emulation of arrays, having a configurable [[Class]] such that |Object.prototype.toString.call(arrayproxy)| can return "[object Array]" seems like a more important imperfection to fix)
I disagree. People can fix this one by themselves: https://gist.github.com/1026960 (I haven't tested, but it gives the idea).

That's kind of gross, though. Non-modular. Clearly Tom was talking about modular or proxy-wise customization of [[ClassName]]. IIRC Allen has done work to separate [[Class]] from [[ClassName]] which should allow proxies to intercede for the latter.


Of course this solution is valid as long as observable side effects of [[Class]] can be redefined.
This is not the case for the .length issue.

Can you give an example of the length issue? Sorry if I missed it.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

David Bruant-4
Le 15/06/2011 17:10, Brendan Eich a écrit :

> On Jun 15, 2011, at 5:19 AM, David Bruant wrote:
>
>> Le 15/06/2011 13:34, Tom Van Cutsem a écrit :
>>> (As an aside: re. the emulation of arrays, having a configurable
>>> [[Class]] such that |Object.prototype.toString.call(arrayproxy)| can
>>> return "[object Array]" seems like a more important imperfection to fix)
>> I disagree. People can fix this one by themselves:
>> https://gist.github.com/1026960 (I haven't tested, but it gives the
>> idea).
>
> That's kind of gross, though.
I agree. My point was just to prove that it's possible. But it's gross
indeed. Moreover, my trick wouldn't work in an environment with several
globals (unless redifining all of them which is gross²)

> Non-modular. Clearly Tom was talking about modular or proxy-wise
> customization of [[ClassName]]. IIRC Allen has done work to separate
> [[Class]] from [[ClassName]] which should allow proxies to intercede
> for the latter.
I'm looking forward to see it coming.


>> Of course this solution is valid as long as observable side effects
>> of [[Class]] can be redefined.
>> This is not the case for the .length issue.
>
> Can you give an example of the length issue? Sorry if I missed it.
Currently, one open issue is deciding whether
Object.get{Own}PropertyDescriptor should say that every proxy property
is configurable (the main pro argument is that it would prevent proxies
from lying by saying that properties aren't and change configuration or
removing at the same time).
Sean has a proposal to have some sort of "separate" records for
non-configurable properties on proxies, both guaranteeing
non-configurable invariants and the ability for proxies to have
non-configurable properties.
However, this proposal prevents from implementing arrays which have a
non-configurable "length" but have a special behavior (relationship with
numeric properties) that wouldn't be emulated by the "separate" records.
So basically, if an ES implementation had a bug on arrays .length
proxies may not be able to fix them.

My position on the open issue is that proxies should not try to enforce
configurable or enumerable since they just cannot.

I'm currently torn between two visions of ECMAScript objects. The former
is a property-based vision: an object is a collection of string -> value
associations. The latter is a Meta-Object Programming contract-based
(MOP) vision. This second vision is more general and can modelize the
former by enforcing invariants and relationship between internal methods
(https://github.com/DavidBruant/PropStackObjects was an experiment in
that direction). I think it's nothing less than a classic
data/computation point of view difference, but considering one or the
other changes the vision on proxies. In the former, Sean's proposal
makes sense. I'm more doubtful on the latter because (in my opinion)
there is no reason to isolate the behavior of some inputs of the MOP
contract methods.
And non-configurable invariants could be enforced on top of the latter
vision, the opposite is not true.

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Allen Wirfs-Brock
In reply to this post by Brendan Eich-3

On Jun 15, 2011, at 8:10 AM, Brendan Eich wrote:

> On Jun 15, 2011, at 5:19 AM, David Bruant wrote:
>
>
>> Of course this solution is valid as long as observable side effects of [[Class]] can be redefined.
>> This is not the case for the .length issue.
>
>
> Can you give an example of the length issue? Sorry if I missed it.
>

From a posting I made earlier in this thread:

> Doesn't this new proposal still preclude using proxies to create an exact emulation of the built-in Array object type.  The "length" property of arrays is specified to be non-configurable yet special behavior must occur each time the value of length is changed.  The proposal would allow "length" to be "fixed"  as an accessor property whose set behavior did the necessary processing.  However, that is also a violation of the Array specification as it requires that "length" exhibit the attributes of a data property.
>
> I emphasize Array when I look at this simply because it is a fairly simple example of the sort of thing that a host object might currently do and the most important use case of proxies for me is the replacement/emulation of host objects.  I really don't know where this idea that non-configurable implies no special semantics comes from.  That isn't the case in the ES5 specification  (10.6,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such properties.  

More generally, for better or worse, Cameron McCormack is right now busily working to publish the last call draft of a Web IDL specification that includes rules for what the attribute settings must be for all DOM properties.  If those rules don't match up with what proxies can express then there will be issues with implementing the DOM in ECMAScript.

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Brendan Eich-3
On Jun 15, 2011, at 8:51 AM, Allen Wirfs-Brock wrote:

> From a posting I made earlier in this thread:
>
>> Doesn't this new proposal still preclude using proxies to create an exact emulation of the built-in Array object type.  The "length" property of arrays is specified to be non-configurable yet special behavior must occur each time the value of length is changed.  The proposal would allow "length" to be "fixed"  as an accessor property whose set behavior did the necessary processing.  However, that is also a violation of the Array specification as it requires that "length" exhibit the attributes of a data property.
>>
>> I emphasize Array when I look at this simply because it is a fairly simple example of the sort of thing that a host object might currently do and the most important use case of proxies for me is the replacement/emulation of host objects.  I really don't know where this idea that non-configurable implies no special semantics comes from.  That isn't the case in the ES5 specification  (10.6,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such properties.  

D'oh, I see.


> More generally, for better or worse, Cameron McCormack is right now busily working to publish the last call draft of a Web IDL specification that includes rules for what the attribute settings must be for all DOM properties.  If those rules don't match up with what proxies can express then there will be issues with implementing the DOM in ECMAScript.

Paging Dr. Van Cutsem!

To emulate length as non-configurable but magically changing its value as a data property may be possible with proxies. It is after all writable.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Allen Wirfs-Brock
In reply to this post by Tom Van Cutsem-3

On Jun 15, 2011, at 4:34 AM, Tom Van Cutsem wrote:

2011/6/14 Allen Wirfs-Brock <[hidden email]>
...
 
I emphasize Array when I look at this simply because it is a fairly simple example of the sort of thing that a host object might currently do and the most important use case of proxies for me is the replacement/emulation of host objects.  I really don't know where this idea that non-configurable implies no special semantics comes from.  That isn't the case in the ES5 specification  (10.6,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such properties.

I'm not sure what you mean by special semantics. If you mean strong guarantees/invariants, then one example would be that a non-writable, non-configurable data property is guaranteed to have a stable value. The proposed strawman allows proxies to define such properties, at the expense of giving up interception of access to such a property.

By "special semantics", I mean any semantics for the Object internal methods other than exactly what is specified in section 8.12.  

The ES specification states requirements but doesn't make any guarantees.  For example, it states a requirement on host objects concerning consistency of value for non-writable, non-configurable data properties.  But it can guarantee that an implementation doesn't have bugs or has simply choosen to ignore that requirement.   Also, the spec. doesn't say that accessing the value of such non-writable/non-configurable properties may not have any side-effects.  As far as I know, nobody has ever actually audited any of the emerging  ES5 browser implementations to see if their DOM implementations fully conform to all of the requirements of the ES5 spec. In the short term, I will be surprised if somebody does this and discoveres that the implementations all fully conform.

In general I see invariants violations as bugs that you normally don't explicitly write defensives code to detect.  You assume the invariant is true and expect any significant violation of the invariant to manifest itself in some buggy behavior of your program.  Any reasonable sized application or framework is gong to have hundreds, if not thousands, of such invariants.  I don't see why the non-writable/non-configurable invariant is particularly any more or less important than any other of the invariants that might be violated using proxies or just using regular ES code.  In particular, I don't understand why that invariant is so important we would degrade the ability to proxies to support some of their primary uses cases.

It may be that for some security scenarios it really is important to have truly frozen data only objects.  I have no problem with supporting that need via the fix trap or something like it.  What I object to is using that use case as a justification for not supporting other important use cases such as accurate emulation of built-in objects or the DOM.

Allen



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Allen Wirfs-Brock
typo in 3rd sentence of 2nd paragraph: "can guarantee" --> "can't guarantee"

On Jun 15, 2011, at 9:26 AM, Allen Wirfs-Brock wrote:


On Jun 15, 2011, at 4:34 AM, Tom Van Cutsem wrote:

2011/6/14 Allen Wirfs-Brock <[hidden email]>
...
 
I emphasize Array when I look at this simply because it is a fairly simple example of the sort of thing that a host object might currently do and the most important use case of proxies for me is the replacement/emulation of host objects.  I really don't know where this idea that non-configurable implies no special semantics comes from.  That isn't the case in the ES5 specification  (10.6,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such properties.

I'm not sure what you mean by special semantics. If you mean strong guarantees/invariants, then one example would be that a non-writable, non-configurable data property is guaranteed to have a stable value. The proposed strawman allows proxies to define such properties, at the expense of giving up interception of access to such a property.

By "special semantics", I mean any semantics for the Object internal methods other than exactly what is specified in section 8.12.  

The ES specification states requirements but doesn't make any guarantees.  For example, it states a requirement on host objects concerning consistency of value for non-writable, non-configurable data properties.  But it can't guarantee that an implementation doesn't have bugs or has simply choosen to ignore that requirement.   Also, the spec. doesn't say that accessing the value of such non-writable/non-configurable properties may not have any side-effects.  As far as I know, nobody has ever actually audited any of the emerging  ES5 browser implementations to see if their DOM implementations fully conform to all of the requirements of the ES5 spec. In the short term, I will be surprised if somebody does this and discoveres that the implementations all fully conform.

In general I see invariants violations as bugs that you normally don't explicitly write defensives code to detect.  You assume the invariant is true and expect any significant violation of the invariant to manifest itself in some buggy behavior of your program.  Any reasonable sized application or framework is gong to have hundreds, if not thousands, of such invariants.  I don't see why the non-writable/non-configurable invariant is particularly any more or less important than any other of the invariants that might be violated using proxies or just using regular ES code.  In particular, I don't understand why that invariant is so important we would degrade the ability to proxies to support some of their primary uses cases.

It may be that for some security scenarios it really is important to have truly frozen data only objects.  I have no problem with supporting that need via the fix trap or something like it.  What I object to is using that use case as a justification for not supporting other important use cases such as accurate emulation of built-in objects or the DOM.

Allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Mark S. Miller-2
In reply to this post by Allen Wirfs-Brock


On Wed, Jun 15, 2011 at 9:26 AM, Allen Wirfs-Brock <[hidden email]> wrote:

On Jun 15, 2011, at 4:34 AM, Tom Van Cutsem wrote:

2011/6/14 Allen Wirfs-Brock <[hidden email]>
...
 
I emphasize Array when I look at this simply because it is a fairly simple example of the sort of thing that a host object might currently do and the most important use case of proxies for me is the replacement/emulation of host objects.  I really don't know where this idea that non-configurable implies no special semantics comes from.  That isn't the case in the ES5 specification  (10.6,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such properties.

I'm not sure what you mean by special semantics. If you mean strong guarantees/invariants, then one example would be that a non-writable, non-configurable data property is guaranteed to have a stable value. The proposed strawman allows proxies to define such properties, at the expense of giving up interception of access to such a property.

By "special semantics", I mean any semantics for the Object internal methods other than exactly what is specified in section 8.12.  

The ES specification states requirements but doesn't make any guarantees.  For example, it states a requirement on host objects concerning consistency of value for non-writable, non-configurable data properties.  But it can guarantee that an implementation doesn't have bugs or has simply choosen to ignore that requirement.   Also, the spec. doesn't say that accessing the value of such non-writable/non-configurable properties may not have any side-effects.  As far as I know, nobody has ever actually audited any of the emerging  ES5 browser implementations to see if their DOM implementations fully conform to all of the requirements of the ES5 spec. In the short term, I will be surprised if somebody does this and discoveres that the implementations all fully conform.

I don't get your point. Host objects aside, I would be surprised if any JavaScript fully conforms to the ES5 spec in any timeframe that can be considered short term. In both cases, when spec violations are discovered, we hope that they get fixed. Otherwise, why have a spec at all?

 

In general I see invariants violations as bugs that you normally don't explicitly write defensives code to detect.  You assume the invariant is true and expect any significant violation of the invariant to manifest itself in some buggy behavior of your program.  Any reasonable sized application or framework is gong to have hundreds, if not thousands, of such invariants.  I don't see why the non-writable/non-configurable invariant is particularly any more or less important than any other of the invariants that might be violated using proxies or just using regular ES code.  In particular, I don't understand why that invariant is so important we would degrade the ability to proxies to support some of their primary uses cases.

It may be that for some security scenarios it really is important to have truly frozen data only objects.  I have no problem with supporting that need via the fix trap or something like it.  What I object to is using that use case as a justification for not supporting other important use cases such as accurate emulation of built-in objects or the DOM.

Allen



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Allen Wirfs-Brock

On Jun 15, 2011, at 9:40 AM, Mark S. Miller wrote:



On Wed, Jun 15, 2011 at 9:26 AM, Allen Wirfs-Brock <[hidden email]> wrote:

On Jun 15, 2011, at 4:34 AM, Tom Van Cutsem wrote:

2011/6/14 Allen Wirfs-Brock <[hidden email]>
...
 
I emphasize Array when I look at this simply because it is a fairly simple example of the sort of thing that a host object might currently do and the most important use case of proxies for me is the replacement/emulation of host objects.  I really don't know where this idea that non-configurable implies no special semantics comes from.  That isn't the case in the ES5 specification  (10.6,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such properties.

I'm not sure what you mean by special semantics. If you mean strong guarantees/invariants, then one example would be that a non-writable, non-configurable data property is guaranteed to have a stable value. The proposed strawman allows proxies to define such properties, at the expense of giving up interception of access to such a property.

By "special semantics", I mean any semantics for the Object internal methods other than exactly what is specified in section 8.12.  

The ES specification states requirements but doesn't make any guarantees.  For example, it states a requirement on host objects concerning consistency of value for non-writable, non-configurable data properties.  But it can guarantee that an implementation doesn't have bugs or has simply choosen to ignore that requirement.   Also, the spec. doesn't say that accessing the value of such non-writable/non-configurable properties may not have any side-effects.  As far as I know, nobody has ever actually audited any of the emerging  ES5 browser implementations to see if their DOM implementations fully conform to all of the requirements of the ES5 spec. In the short term, I will be surprised if somebody does this and discoveres that the implementations all fully conform.

I don't get your point. Host objects aside, I would be surprised if any JavaScript fully conforms to the ES5 spec in any timeframe that can be considered short term. In both cases, when spec violations are discovered, we hope that they get fixed. Otherwise, why have a spec at all?


Reason for restricting the configurable attribute of properties of Proxy objects seems to be trading off an attempt to guarantee an resonable invariant but at the cost of limiting the utility of proxies. My point is that such guarantees are never more than requirements that may or may not be met by actual implementations.  If the requirement is there for security reasons then it probably isn't enough for you to blindly depend upon it.  Given that, I don't see why proxies should be partially crippled in a attempt to turn a requirement into a guarantee. I'm fine with stating a requirement for proxy implementors just like we do for host object implementors.  I'm not fine with it being a lynchpin of enforced proxy semantics. 

Allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem-3
In reply to this post by Brendan Eich-3
2011/6/15 Brendan Eich <[hidden email]>
On Jun 15, 2011, at 8:51 AM, Allen Wirfs-Brock wrote:
> More generally, for better or worse, Cameron McCormack is right now busily working to publish the last call draft of a Web IDL specification that includes rules for what the attribute settings must be for all DOM properties.  If those rules don't match up with what proxies can express then there will be issues with implementing the DOM in ECMAScript.

Aside from the configurable attribute (which we are now discussing), proxies are able to emulate all other attribute values, so I can't immediately think of any other use cases that proxies currently cannot deal with.
 
Paging Dr. Van Cutsem!

To emulate length as non-configurable but magically changing its value as a data property may be possible with proxies. It is after all writable.

Ah, good suggestion. The fixed properties strawman would indeed allow this. First, one defines "length" as a non-configurable property on a fresh arrayProxy, thereby fixing the property:

Object.defineProperty(arrayProxy, "length",
  { value: 0,
    writable: true,
    enumerable: false,
    configurable: false });

Given that we provide all traps with a reference to the proxy they're currently servicing (as per one of the pending strawmen), the handler for arrayProxy can then update the fixed "length" property within a trap by performing:

Object.defineProperty(arrayProxy, "length", { value: newValue });

This will modify the fixed property, which is legal since it is writable.
It may not be very elegant, but at least it's doable.

To be clear: what the strawman still doesn't allow is that a proxy would be able to emulate a non-writable, non-configurable data property whose value can still change.

Cheers,
Tom

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Brendan Eich-3
On Jun 15, 2011, at 1:38 PM, Tom Van Cutsem wrote:

> Object.defineProperty(arrayProxy, "length", { value: newValue });
>
> This will modify the fixed property, which is legal since it is writable.
> It may not be very elegant, but at least it's doable.

Great. When in doubt, use brute force.


> To be clear: what the strawman still doesn't allow is that a proxy would be able to emulate a non-writable, non-configurable data property whose value can still change.

Right, and I claim that is DOM crazyland host object behavior to leave behind in browser host object implementations.

We're redoing Gecko's DOM to be self-hosted in certain ways (nodelists via proxies) and experimenting with a fully self-hosted DOM. WebIDL is evolving to match.

Who needs more crazy? Not me.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem-3
In reply to this post by Tom Van Cutsem-3
Just realized: even though an arrayProxy could update its fixed "length" property, it would not be able to intercept updates "from the outside" (i.e. updates to "length" by objects other than the handler). I guess that capability is also needed to be able to "shrink" an array if its "length" is decreased.

Perhaps the strawman should be refined such that the defineProperty trap is triggered even on redefinition of fixed properties. The trap's returned descriptor would again act as the "real" descriptor that is used to redefine the actual fixed property inside of the proxy using the built-in [[DefineOwnProperty]] algorithm.

Cheers,
Tom

2011/6/15 Tom Van Cutsem <tomvc.be@gmail.com>
2011/6/15 Brendan Eich <[hidden email]>
On Jun 15, 2011, at 8:51 AM, Allen Wirfs-Brock wrote:
> More generally, for better or worse, Cameron McCormack is right now busily working to publish the last call draft of a Web IDL specification that includes rules for what the attribute settings must be for all DOM properties.  If those rules don't match up with what proxies can express then there will be issues with implementing the DOM in ECMAScript.

Aside from the configurable attribute (which we are now discussing), proxies are able to emulate all other attribute values, so I can't immediately think of any other use cases that proxies currently cannot deal with.
 
Paging Dr. Van Cutsem!

To emulate length as non-configurable but magically changing its value as a data property may be possible with proxies. It is after all writable.

Ah, good suggestion. The fixed properties strawman would indeed allow this. First, one defines "length" as a non-configurable property on a fresh arrayProxy, thereby fixing the property:

Object.defineProperty(arrayProxy, "length",
  { value: 0,
    writable: true,
    enumerable: false,
    configurable: false });

Given that we provide all traps with a reference to the proxy they're currently servicing (as per one of the pending strawmen), the handler for arrayProxy can then update the fixed "length" property within a trap by performing:

Object.defineProperty(arrayProxy, "length", { value: newValue });

This will modify the fixed property, which is legal since it is writable.
It may not be very elegant, but at least it's doable.

To be clear: what the strawman still doesn't allow is that a proxy would be able to emulate a non-writable, non-configurable data property whose value can still change.

Cheers,
Tom


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
1234567