[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

David Bruant-4
Le 15/06/2011 23:01, Tom Van Cutsem a écrit :
> 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.
In a way, the fixed properties proposal make proxies bicephal. For some
inputs (property names), they plug their handler-provided MOP-brain and
for some others, they plug a native object MOP-brain (ES5 - 8.12). These
brains cannot communicate. This is why changing .length in the "native
object brain" has no effect in the other brain (which handles numeric
properties(...unless some of these are non-configurable)). And I think
it has been said before, but there would be no logging possible for
non-configurable properties in the context of the fixed properties
strawman since native MOP-brain doesn't allow that.

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

Mark S. Miller-2
On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
Le 15/06/2011 23:01, Tom Van Cutsem a écrit :
> 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.

There's something I don't understand about this whole conversation. Why does our emulated array need to claim that its length property is a non-configurable data property, as opposed to
* a non-configurable accessor property
* a configurable data property
* a configurable accessor property
?
There can't be any ES3 code that would be broken by any of these other choices, since ES3 code can't ask about these attributes.


 
In a way, the fixed properties proposal make proxies bicephal. For some
inputs (property names), they plug their handler-provided MOP-brain and
for some others, they plug a native object MOP-brain (ES5 - 8.12). These
brains cannot communicate. This is why changing .length in the "native
object brain" has no effect in the other brain (which handles numeric
properties(...unless some of these are non-configurable)). And I think
it has been said before, but there would be no logging possible for
non-configurable properties in the context of the fixed properties
strawman since native MOP-brain doesn't allow that.
 
Cute metaphor. But as Tom's code showed, the proxy can create fixed (non-configurable) accessor properties whose getters and setters form a corpus callosum ;).

--
    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 Jun 15, 2011, at 3:53 PM, Mark S. Miller wrote:

On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
Le 15/06/2011 23:01, Tom Van Cutsem a écrit :
> 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.

There's something I don't understand about this whole conversation. Why does our emulated array need to claim that its length property is a non-configurable data property, as opposed to
* a non-configurable accessor property
* a configurable data property
* a configurable accessor property
?
There can't be any ES3 code that would be broken by any of these other choices, since ES3 code can't ask about these attributes.

ES5 code can. Isn't that enough of an objection? People are filing bugs over such observable (with ES5's meta-object API) differences among engines, especially in the DOM where this is driving the WebIDL spec.

/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 Mark S. Miller-2

On Jun 15, 2011, at 3:53 PM, Mark S. Miller wrote:

On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
Le 15/06/2011 23:01, Tom Van Cutsem a écrit :
> 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.

There's something I don't understand about this whole conversation. Why does our emulated array need to claim that its length property is a non-configurable data property, as opposed to
* a non-configurable accessor property
* a configurable data property
* a configurable accessor property
?
Because the ES5 spec. say the length property has attributes: writable: true, enumerable: false, configurable: false.  any of the above would be a minor variation, but still a variation from the specification.  If you feel comfortable with accepting that variation what other variations would you also be comfortable with accepting?  What variations would others be comfortable with accepting and what if their areas of comfort are different from yours?  How about a variation that ignores the restrictions on non-configurable Proxy properties. 


There can't be any ES3 code that would be broken by any of these other choices, since ES3 code can't ask about these attributes.


The issue isn't only about Array length or compatibility with existing user code.  It is about whether or not Proxies have the power to implement the sort of objects that have been created in the past by host objects and implementation extensions and even the ESstandard.  What if somebody said,  I have this great new system implementation language but it has an limitation that prevents it from implementing some features of the ES standard.  Is it ok, to just get the implementation as close as I can.  That's what they would likely do regardless of what you say, but would you be happy about that?


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

Mark S. Miller-2
In reply to this post by Brendan Eich-3
On Wed, Jun 15, 2011 at 4:01 PM, Brendan Eich <[hidden email]> wrote:
On Jun 15, 2011, at 3:53 PM, Mark S. Miller wrote:

On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
Le 15/06/2011 23:01, Tom Van Cutsem a écrit :
> 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.

There's something I don't understand about this whole conversation. Why does our emulated array need to claim that its length property is a non-configurable data property, as opposed to
* a non-configurable accessor property
* a configurable data property
* a configurable accessor property
?
There can't be any ES3 code that would be broken by any of these other choices, since ES3 code can't ask about these attributes.

ES5 code can. Isn't that enough of an objection? People are filing bugs over such observable (with ES5's meta-object API) differences among engines, especially in the DOM where this is driving the WebIDL spec.

Objection to what? This is what I'm confused about. You're saying that there is ES5 code which actually cares about these assurances, and it's breaking because we don't enable proxies to issue these assurances falsely. Either the ES5 code cares or it doesn't. We need to ask, why does it care? If you enable proxies to lie, so that such ES5 code then proceeds under false assurances, is this a more or less severe breakage of that ES5 code? It depends on why the ES5 code cares about the answer.


On Wed, Jun 15, 2011 at 4:14 PM, Allen Wirfs-Brock <[hidden email]> wrote:

Because the ES5 spec. say the length property has attributes: writable: true, enumerable: false, configurable: false.  any of the above would be a minor variation, but still a variation from the specification.  If you feel comfortable with accepting that variation what other variations would you also be comfortable with accepting?  What variations would others be comfortable with accepting and what if their areas of comfort are different from yours?  How about a variation that ignores the restrictions on non-configurable Proxy properties. 

I really don't understand what we're talking about. On the one hand, I'm talking about an inability of a proxy to perfectly emulate an ES5 array within the ES5 spec. On the other hand, you're talking about relaxing the ES5 spec so that a proxy can appear to perfectly emulate an ES5 array while not doing so. These do not seem comparable. If these are comparable, what am I missing? Really, I'm not arguing yet, I'm asking for clarification, because I do not understand this conversation.
 


There can't be any ES3 code that would be broken by any of these other choices, since ES3 code can't ask about these attributes.


The issue isn't only about Array length or compatibility with existing user code.  It is about whether or not Proxies have the power to implement the sort of objects that have been created in the past by host objects and implementation extensions and even the ESstandard.  What if somebody said,  I have this great new system implementation language but it has an limitation that prevents it from implementing some features of the ES standard.  Is it ok, to just get the implementation as close as I can.  That's what they would likely do regardless of what you say, but would you be happy about that?

Arrays aren't host objects. And the legacy host object behavior that WebIDL must be compat with predates ES5. To take a simple position that may be clarifying, why not have WebIDL's JS binding specify that *all* properties of host objects must be configurable? Really? This would allow host objects to do what they want within the spec, would allow proxies to emulate host objects perfectly within the spec, and would all be perfectly compat with all legacy host object behavior. I would have no objection to such a WebIDL JS-binding specification.

 


--
    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 4:25 PM, Mark S. Miller wrote:

On Wed, Jun 15, 2011 at 4:01 PM, Brendan Eich <[hidden email]> wrote:
On Jun 15, 2011, at 3:53 PM, Mark S. Miller wrote:

On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
Le 15/06/2011 23:01, Tom Van Cutsem a écrit :
> 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.

There's something I don't understand about this whole conversation. Why does our emulated array need to claim that its length property is a non-configurable data property, as opposed to
* a non-configurable accessor property
* a configurable data property
* a configurable accessor property
?
There can't be any ES3 code that would be broken by any of these other choices, since ES3 code can't ask about these attributes.

ES5 code can. Isn't that enough of an objection? People are filing bugs over such observable (with ES5's meta-object API) differences among engines, especially in the DOM where this is driving the WebIDL spec.

Objection to what? This is what I'm confused about. You're saying that there is ES5 code which actually cares about these assurances, and it's breaking because we don't enable proxies to issue these assurances falsely. Either the ES5 code cares or it doesn't. We need to ask, why does it care? If you enable proxies to lie, so that such ES5 code then proceeds under false assurances, is this a more or less severe breakage of that ES5 code? It depends on why the ES5 code cares about the answer.

This line of argument is remarkably similar to discussion have had on a number of occasions with JavaScript implementor who were looking for license to ignore or modify part of the ES5 specified behavior.  "nobody depends upon this, something will be better if we don't have to do that, it was stupid for the spec. to say that so I think I can just ignore it..."



On Wed, Jun 15, 2011 at 4:14 PM, Allen Wirfs-Brock <[hidden email]> wrote:

Because the ES5 spec. say the length property has attributes: writable: true, enumerable: false, configurable: false.  any of the above would be a minor variation, but still a variation from the specification.  If you feel comfortable with accepting that variation what other variations would you also be comfortable with accepting?  What variations would others be comfortable with accepting and what if their areas of comfort are different from yours?  How about a variation that ignores the restrictions on non-configurable Proxy properties. 

I really don't understand what we're talking about. On the one hand, I'm talking about an inability of a proxy to perfectly emulate an ES5 array within the ES5 spec. On the other hand, you're talking about relaxing the ES5 spec so that a proxy can appear to perfectly emulate an ES5 array while not doing so. These do not seem comparable. If these are comparable, what am I missing? Really, I'm not arguing yet, I'm asking for clarification, because I do not understand this conversation.

No, I'm not talking about relaxing the ES5 spec.  I'm talking about what is necessary to enable ES.next to be used  as an implementation language for the ES5 spec.  Proxy are a metalevel facility that supports intercession.  They are being added to enable ES programs to do things that they cannot directly do without dropping down to such a metalevel.  What are some of these things that we want to enable.  They are things that modify the operation of the "internal methods" that define the semantics of objects.  What sort of modification to these operations are we willing to support?  Perhaps, this is an area where we have never adequately reached consensus on. My personal stake in the ground is that I want to be able to implement all the ES5 built-in objects in full conformance to the ES5 specification. I also want to be able to implement all of the web app APIs including the DOM that are now implemented outside of JavaScript using engine specific host object foreign function interfaces.  As a stake in the ground, I don't really case how these objects might be changed to more easily fit the Proxy specification. What I care about is that there are things that some of these objects do that cannot be accomplished using proxies. To me that says that proxies are not meeting my full expectations of what they should enable.


 


There can't be any ES3 code that would be broken by any of these other choices, since ES3 code can't ask about these attributes.


The issue isn't only about Array length or compatibility with existing user code.  It is about whether or not Proxies have the power to implement the sort of objects that have been created in the past by host objects and implementation extensions and even the ESstandard.  What if somebody said,  I have this great new system implementation language but it has an limitation that prevents it from implementing some features of the ES standard.  Is it ok, to just get the implementation as close as I can.  That's what they would likely do regardless of what you say, but would you be happy about that?

Arrays aren't host objects. And the legacy host object behavior that WebIDL must be compat with predates ES5. To take a simple position that may be clarifying, why not have WebIDL's JS binding specify that *all* properties of host objects must be configurable? Really? This would allow host objects to do what they want within the spec, would allow proxies to emulate host objects perfectly within the spec, and would all be perfectly compat with all legacy host object behavior. I would have no objection to such a WebIDL JS-binding specification.

This isn't about how WebIDL might be modified to make it more compatible with ES, that's actually what Cameroon is trying to do right now   I see implementing ES5 built-in and implementing web app APIs are two important use cases for proxies but  I'm currently bringing those up only as specific test cases for the overall power of proxies as currently specified. Both the built-ins and current host objects exist because of loopholes that allow them to escape from the confines of normal ES native object semantics.  We want to allow metalevel programming in ES to accomplish similar things. What capabilities do we need to actually support at that metalevel?  I'm not sure.  But in the built-ins and existing browser host objects (which actually had quite wide variation across implementations) we have a fairly large corpus of what implementation have actually done at this level. I'm arguing that if we don't have the ability to replicate that corpus then we don't yet have an minimally adequate set of metalevel capabilities. 








 


--
    Cheers,
    --MarkM
_______________________________________________
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


On Wed, Jun 15, 2011 at 5:13 PM, Allen Wirfs-Brock <[hidden email]> wrote:

On Jun 15, 2011, at 4:25 PM, Mark S. Miller wrote:

On Wed, Jun 15, 2011 at 4:01 PM, Brendan Eich <[hidden email]> wrote:
On Jun 15, 2011, at 3:53 PM, Mark S. Miller wrote:

On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
Le 15/06/2011 23:01, Tom Van Cutsem a écrit :
> 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.

There's something I don't understand about this whole conversation. Why does our emulated array need to claim that its length property is a non-configurable data property, as opposed to
* a non-configurable accessor property
* a configurable data property
* a configurable accessor property
?
There can't be any ES3 code that would be broken by any of these other choices, since ES3 code can't ask about these attributes.

ES5 code can. Isn't that enough of an objection? People are filing bugs over such observable (with ES5's meta-object API) differences among engines, especially in the DOM where this is driving the WebIDL spec.

Objection to what? This is what I'm confused about. You're saying that there is ES5 code which actually cares about these assurances, and it's breaking because we don't enable proxies to issue these assurances falsely. Either the ES5 code cares or it doesn't. We need to ask, why does it care? If you enable proxies to lie, so that such ES5 code then proceeds under false assurances, is this a more or less severe breakage of that ES5 code? It depends on why the ES5 code cares about the answer.

This line of argument is remarkably similar to discussion have had on a number of occasions with JavaScript implementor who were looking for license to ignore or modify part of the ES5 specified behavior.  "nobody depends upon this, something will be better if we don't have to do that, it was stupid for the spec. to say that so I think I can just ignore it..."

At time point, I still do not understand you. The lines you think are remarkably similar seem diametrically opposed. The "nobody..." line you think is similar to my line I find to instead be similar to yours. However, I think I understand what you say below. If, from my response, it seems that we're understanding each other below, perhaps we can skip our inability to communicate above?

Alternatively, if anyone here thinks they understand both what Allen is trying to say and what I am trying to say, perhaps you can help explain us to each other?


 



On Wed, Jun 15, 2011 at 4:14 PM, Allen Wirfs-Brock <[hidden email]> wrote:

Because the ES5 spec. say the length property has attributes: writable: true, enumerable: false, configurable: false.  any of the above would be a minor variation, but still a variation from the specification.  If you feel comfortable with accepting that variation what other variations would you also be comfortable with accepting?  What variations would others be comfortable with accepting and what if their areas of comfort are different from yours?  How about a variation that ignores the restrictions on non-configurable Proxy properties. 

I really don't understand what we're talking about. On the one hand, I'm talking about an inability of a proxy to perfectly emulate an ES5 array within the ES5 spec. On the other hand, you're talking about relaxing the ES5 spec so that a proxy can appear to perfectly emulate an ES5 array while not doing so. These do not seem comparable. If these are comparable, what am I missing? Really, I'm not arguing yet, I'm asking for clarification, because I do not understand this conversation.

No, I'm not talking about relaxing the ES5 spec.  I'm talking about what is necessary to enable ES.next to be used  as an implementation language for the ES5 spec.  Proxy are a metalevel facility that supports intercession.  They are being added to enable ES programs to do things that they cannot directly do without dropping down to such a metalevel.  What are some of these things that we want to enable.  They are things that modify the operation of the "internal methods" that define the semantics of objects.  What sort of modification to these operations are we willing to support?  Perhaps, this is an area where we have never adequately reached consensus on. My personal stake in the ground is that I want to be able to implement all the ES5 built-in objects in full conformance to the ES5 specification. I also want to be able to implement all of the web app APIs including the DOM that are now implemented outside of JavaScript using engine specific host object foreign function interfaces.  As a stake in the ground, I don't really case how these objects might be changed to more easily fit the Proxy specification. What I care about is that there are things that some of these objects do that cannot be accomplished using proxies. To me that says that proxies are not meeting my full expectations of what they should enable.

Ok good, I'll take you up on that. I propose that ES-next arrays differ from ES5 arrays in that their 'length' property appears to be a non-configurable accessor property. Clearly, that better reflects the way Array's 'length' works anyway. Alternatively, if there's some problem with that, I propose that array 'length' appears to be a configurable data property that arrays nevertheless refuse to delete. Either way, proxies would then be able to emulate them faithfully.


 


 


There can't be any ES3 code that would be broken by any of these other choices, since ES3 code can't ask about these attributes.


The issue isn't only about Array length or compatibility with existing user code.  It is about whether or not Proxies have the power to implement the sort of objects that have been created in the past by host objects and implementation extensions and even the ESstandard.  What if somebody said,  I have this great new system implementation language but it has an limitation that prevents it from implementing some features of the ES standard.  Is it ok, to just get the implementation as close as I can.  That's what they would likely do regardless of what you say, but would you be happy about that?

Arrays aren't host objects. And the legacy host object behavior that WebIDL must be compat with predates ES5. To take a simple position that may be clarifying, why not have WebIDL's JS binding specify that *all* properties of host objects must be configurable? Really? This would allow host objects to do what they want within the spec, would allow proxies to emulate host objects perfectly within the spec, and would all be perfectly compat with all legacy host object behavior. I would have no objection to such a WebIDL JS-binding specification.

This isn't about how WebIDL might be modified to make it more compatible with ES, that's actually what Cameroon is trying to do right now   I see implementing ES5 built-in and implementing web app APIs are two important use cases for proxies but  I'm currently bringing those up only as specific test cases for the overall power of proxies as currently specified. Both the built-ins and current host objects exist because of loopholes that allow them to escape from the confines of normal ES native object semantics.  We want to allow metalevel programming in ES to accomplish similar things. What capabilities do we need to actually support at that metalevel?  I'm not sure.  But in the built-ins and existing browser host objects (which actually had quite wide variation across implementations) we have a fairly large corpus of what implementation have actually done at this level. I'm arguing that if we don't have the ability to replicate that corpus then we don't yet have an minimally adequate set of metalevel capabilities. 

So if all properties of host objects were configurable, would they no longer demonstrate that we don't have minimal adequacy? If we fix array 'length' as above, what remaining problem cases do we have for achieving this minimal adequacy? Can we fix these remaining problem cases in this same way?


--
    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
In reply to this post by Mark S. Miller-2
On Jun 15, 2011, at 4:25 PM, Mark S. Miller wrote:

ES5 code can. Isn't that enough of an objection? People are filing bugs over such observable (with ES5's meta-object API) differences among engines, especially in the DOM where this is driving the WebIDL spec.

Objection to what? This is what I'm confused about.

Much of it is testers wanting conformance. Nerds love pro-forma scoring, and with some justice: interoperation bugs hide in bug habitat created by spec-cheating on the part of implementors.

/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
In reply to this post by Mark S. Miller-2
Le 16/06/2011 00:53, Mark S. Miller a écrit :
On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
 
In a way, the fixed properties proposal make proxies bicephal. For some
inputs (property names), they plug their handler-provided MOP-brain and
for some others, they plug a native object MOP-brain (ES5 - 8.12). These
brains cannot communicate. This is why changing .length in the "native
object brain" has no effect in the other brain (which handles numeric
properties(...unless some of these are non-configurable)). And I think
it has been said before, but there would be no logging possible for
non-configurable properties in the context of the fixed properties
strawman since native MOP-brain doesn't allow that.
 
Cute metaphor. But as Tom's code showed, the proxy can create fixed (non-configurable) accessor properties whose getters and setters form a corpus callosum ;).
Interactions with getter/setter is already a good thing, but I think it's not enough. ES5 offers a very fine-grained API to study objects. If we pretend to be able to emulate arrays based on proxies, we should be able to emulate everything including answering correctly when it comes to "is it a data or an accessor property descriptor?".
For instance, for a data property descriptor, even if non-configurable, "writable" can be changed from true to false (then it cannot be changed afterward). This behavior is not possible when dealing with getter/setters.
With fixed properties Tom's code, it is not possible to change an array's length from writable to not writable. Trying to do so would throw an error (because the property is non-configurable and any attempt to switch from accessor to data property descriptor throw an error (or just reject?)).

I'd like to insist on the ability for proxies to be able to emulate native arrays (and new ES5 Object.* API interaction in particular) especially because currently, SpiderMonkey has a problem with redefining ".length" on arrays. See https://bugzilla.mozilla.org/show_bug.cgi?id=598996
I wish proxies to be able to compensate if there is such a bug (in any ES implementation) and I need this level of spec conformance.
This discredits the current fixed properties proposal (especially the getter/setter compensation code), I think.

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

seaneagan1
How about *optional* property fixing as a compromise?  We could
replace the configurability check of the "defineProperty" trap return
value with a check of whether the return value is an object, in which
case it would be treated as a property descriptor to fix the property
to, otherwise the return value would just be ignored.

On Thu, Jun 16, 2011 at 4:18 AM, David Bruant <[hidden email]> wrote:

> Le 16/06/2011 00:53, Mark S. Miller a écrit :
>
> On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
>
>>
>> In a way, the fixed properties proposal make proxies bicephal. For some
>> inputs (property names), they plug their handler-provided MOP-brain and
>> for some others, they plug a native object MOP-brain (ES5 - 8.12). These
>> brains cannot communicate. This is why changing .length in the "native
>> object brain" has no effect in the other brain (which handles numeric
>> properties(...unless some of these are non-configurable)). And I think
>> it has been said before, but there would be no logging possible for
>> non-configurable properties in the context of the fixed properties
>> strawman since native MOP-brain doesn't allow that.
>
>
> Cute metaphor. But as Tom's code showed, the proxy can create fixed
> (non-configurable) accessor properties whose getters and setters form a
> corpus callosum ;).
>
> Interactions with getter/setter is already a good thing, but I think it's
> not enough. ES5 offers a very fine-grained API to study objects. If we
> pretend to be able to emulate arrays based on proxies, we should be able to
> emulate everything including answering correctly when it comes to "is it a
> data or an accessor property descriptor?".
> For instance, for a data property descriptor, even if non-configurable,
> "writable" can be changed from true to false (then it cannot be changed
> afterward). This behavior is not possible when dealing with getter/setters.
> With fixed properties Tom's code, it is not possible to change an array's
> length from writable to not writable. Trying to do so would throw an error
> (because the property is non-configurable and any attempt to switch from
> accessor to data property descriptor throw an error (or just reject?)).
>
> I'd like to insist on the ability for proxies to be able to emulate native
> arrays (and new ES5 Object.* API interaction in particular) especially
> because currently, SpiderMonkey has a problem with redefining ".length" on
> arrays. See https://bugzilla.mozilla.org/show_bug.cgi?id=598996
> I wish proxies to be able to compensate if there is such a bug (in any ES
> implementation) and I need this level of spec conformance.
> This discredits the current fixed properties proposal (especially the
> getter/setter compensation code), I think.
>
> David
>
> _______________________________________________
> 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

seaneagan1
Sorry, I meant remove the configurability check of the
"getOwnPropertyDescriptor" and "getPropertyDescriptor" trap return
values, and add a check as to whether the "defineProperty" trap return
value is an object to fix the property to.

On Thu, Jun 16, 2011 at 8:12 AM, Sean Eagan <[hidden email]> wrote:

> How about *optional* property fixing as a compromise?  We could
> replace the configurability check of the "defineProperty" trap return
> value with a check of whether the return value is an object, in which
> case it would be treated as a property descriptor to fix the property
> to, otherwise the return value would just be ignored.
>
> On Thu, Jun 16, 2011 at 4:18 AM, David Bruant <[hidden email]> wrote:
>> Le 16/06/2011 00:53, Mark S. Miller a écrit :
>>
>> On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
>>
>>>
>>> In a way, the fixed properties proposal make proxies bicephal. For some
>>> inputs (property names), they plug their handler-provided MOP-brain and
>>> for some others, they plug a native object MOP-brain (ES5 - 8.12). These
>>> brains cannot communicate. This is why changing .length in the "native
>>> object brain" has no effect in the other brain (which handles numeric
>>> properties(...unless some of these are non-configurable)). And I think
>>> it has been said before, but there would be no logging possible for
>>> non-configurable properties in the context of the fixed properties
>>> strawman since native MOP-brain doesn't allow that.
>>
>>
>> Cute metaphor. But as Tom's code showed, the proxy can create fixed
>> (non-configurable) accessor properties whose getters and setters form a
>> corpus callosum ;).
>>
>> Interactions with getter/setter is already a good thing, but I think it's
>> not enough. ES5 offers a very fine-grained API to study objects. If we
>> pretend to be able to emulate arrays based on proxies, we should be able to
>> emulate everything including answering correctly when it comes to "is it a
>> data or an accessor property descriptor?".
>> For instance, for a data property descriptor, even if non-configurable,
>> "writable" can be changed from true to false (then it cannot be changed
>> afterward). This behavior is not possible when dealing with getter/setters.
>> With fixed properties Tom's code, it is not possible to change an array's
>> length from writable to not writable. Trying to do so would throw an error
>> (because the property is non-configurable and any attempt to switch from
>> accessor to data property descriptor throw an error (or just reject?)).
>>
>> I'd like to insist on the ability for proxies to be able to emulate native
>> arrays (and new ES5 Object.* API interaction in particular) especially
>> because currently, SpiderMonkey has a problem with redefining ".length" on
>> arrays. See https://bugzilla.mozilla.org/show_bug.cgi?id=598996
>> I wish proxies to be able to compensate if there is such a bug (in any ES
>> implementation) and I need this level of spec conformance.
>> This discredits the current fixed properties proposal (especially the
>> getter/setter compensation code), I think.
>>
>> David
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
>
> --
> Sean Eagan
>



--
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

seaneagan1
I remember Allen brought up some concerns before about the strictness
of the "fix" trap as well.  The same idea could be applied there, such
that a proxy author could return a non-object value if they want to
still be able to intercess, and they could explicitly throw a
TypeError if they want to indicate that the object cannot be made
non-extensible / sealed / frozen.

On Thu, Jun 16, 2011 at 8:15 AM, Sean Eagan <[hidden email]> wrote:

> Sorry, I meant remove the configurability check of the
> "getOwnPropertyDescriptor" and "getPropertyDescriptor" trap return
> values, and add a check as to whether the "defineProperty" trap return
> value is an object to fix the property to.
>
> On Thu, Jun 16, 2011 at 8:12 AM, Sean Eagan <[hidden email]> wrote:
>> How about *optional* property fixing as a compromise?  We could
>> replace the configurability check of the "defineProperty" trap return
>> value with a check of whether the return value is an object, in which
>> case it would be treated as a property descriptor to fix the property
>> to, otherwise the return value would just be ignored.
>>
>> On Thu, Jun 16, 2011 at 4:18 AM, David Bruant <[hidden email]> wrote:
>>> Le 16/06/2011 00:53, Mark S. Miller a écrit :
>>>
>>> On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
>>>
>>>>
>>>> In a way, the fixed properties proposal make proxies bicephal. For some
>>>> inputs (property names), they plug their handler-provided MOP-brain and
>>>> for some others, they plug a native object MOP-brain (ES5 - 8.12). These
>>>> brains cannot communicate. This is why changing .length in the "native
>>>> object brain" has no effect in the other brain (which handles numeric
>>>> properties(...unless some of these are non-configurable)). And I think
>>>> it has been said before, but there would be no logging possible for
>>>> non-configurable properties in the context of the fixed properties
>>>> strawman since native MOP-brain doesn't allow that.
>>>
>>>
>>> Cute metaphor. But as Tom's code showed, the proxy can create fixed
>>> (non-configurable) accessor properties whose getters and setters form a
>>> corpus callosum ;).
>>>
>>> Interactions with getter/setter is already a good thing, but I think it's
>>> not enough. ES5 offers a very fine-grained API to study objects. If we
>>> pretend to be able to emulate arrays based on proxies, we should be able to
>>> emulate everything including answering correctly when it comes to "is it a
>>> data or an accessor property descriptor?".
>>> For instance, for a data property descriptor, even if non-configurable,
>>> "writable" can be changed from true to false (then it cannot be changed
>>> afterward). This behavior is not possible when dealing with getter/setters.
>>> With fixed properties Tom's code, it is not possible to change an array's
>>> length from writable to not writable. Trying to do so would throw an error
>>> (because the property is non-configurable and any attempt to switch from
>>> accessor to data property descriptor throw an error (or just reject?)).
>>>
>>> I'd like to insist on the ability for proxies to be able to emulate native
>>> arrays (and new ES5 Object.* API interaction in particular) especially
>>> because currently, SpiderMonkey has a problem with redefining ".length" on
>>> arrays. See https://bugzilla.mozilla.org/show_bug.cgi?id=598996
>>> I wish proxies to be able to compensate if there is such a bug (in any ES
>>> implementation) and I need this level of spec conformance.
>>> This discredits the current fixed properties proposal (especially the
>>> getter/setter compensation code), I think.
>>>
>>> David
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>>
>> --
>> Sean Eagan
>>
>
>
>
> --
> Sean Eagan
>



--
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

David Bruant-4
In reply to this post by seaneagan1
Le 16/06/2011 15:15, Sean Eagan a écrit :

> Sorry, I meant remove the configurability check of the
> "getOwnPropertyDescriptor" and "getPropertyDescriptor" trap return
> values, and add a check as to whether the "defineProperty" trap return
> value is an object to fix the property to.
>
> On Thu, Jun 16, 2011 at 8:12 AM, Sean Eagan<[hidden email]>  wrote:
>> How about *optional* property fixing as a compromise?  We could
>> replace the configurability check of the "defineProperty" trap return
>> value with a check of whether the return value is an object, in which
>> case it would be treated as a property descriptor to fix the property
>> to, otherwise the return value would just be ignored.
If you replace the compulsory configurability check with an opt-in (by
choosing a particular return value to defineProperty trap), then
"optional property fixing" means "no property fixing", because the
optional part could be implemented as a library on top of proxies
without configurability check.

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

David Bruant-4
In reply to this post by Mark S. Miller-2
Le 16/06/2011 00:53, Mark S. Miller a écrit :
On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
In a way, the fixed properties proposal make proxies bicephal. For some
inputs (property names), they plug their handler-provided MOP-brain and
for some others, they plug a native object MOP-brain (ES5 - 8.12). These
brains cannot communicate. This is why changing .length in the "native
object brain" has no effect in the other brain (which handles numeric
properties(...unless some of these are non-configurable)). And I think
it has been said before, but there would be no logging possible for
non-configurable properties in the context of the fixed properties
strawman since native MOP-brain doesn't allow that.
 
Cute metaphor. But as Tom's code showed, the proxy can create fixed (non-configurable) accessor properties whose getters and setters form a corpus callosum ;).
I think I see also a potential security issue. In Tom's code, getters and setters of the non-configurable properties trigger code of what was in the handler. This is useful as a user to keep triggering the get and set traps, but it also leaks a reference to these functions (after a call to Object.getOwnPropertyDescriptor). In the current proposal, before a property becomes non-configurable, there is no access to any trap (unless having access to the object which implies having indirect access to all traps or the handler itself). After becoming a non-configurable accessor property, the get and set trap applied to the non-configurable properties become available as independant functions that can be passed around.
Currently, one can revoke the access to an object with a membrane/wrapper, but with the leak, I think that all getter/setters will have to be wrapped as well (their call trap in particular)? Ok, maybe there is no security issue, but it adds a little bit more work.

I was first enthousiastic by the general idea of keeping get/set traps through getter/setters (came up first with the fix trap, I think), but since there is an API allowing to extract these functions independently, I'm not really sure it's a good idea (in general) anymore.

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

David Bruant-4
In reply to this post by David Bruant-4
Le 16/06/2011 15:26, David Bruant a écrit :

> Le 16/06/2011 15:15, Sean Eagan a écrit :
>> Sorry, I meant remove the configurability check of the
>> "getOwnPropertyDescriptor" and "getPropertyDescriptor" trap return
>> values, and add a check as to whether the "defineProperty" trap return
>> value is an object to fix the property to.
>>
>> On Thu, Jun 16, 2011 at 8:12 AM, Sean Eagan<[hidden email]>  
>> wrote:
>>> How about *optional* property fixing as a compromise?  We could
>>> replace the configurability check of the "defineProperty" trap return
>>> value with a check of whether the return value is an object, in which
>>> case it would be treated as a property descriptor to fix the property
>>> to, otherwise the return value would just be ignored.
> If you replace the compulsory configurability check with an opt-in (by
> choosing a particular return value to defineProperty trap), then
> "optional property fixing" means "no property fixing", because the
> optional part could be implemented as a library on top of proxies
> without configurability check.
...
And it doesn't solve the bicephality issue. One thing that proxies allow
is inter-property intelligence. That's why they allow emulation of the
relationship between "length" and numeric properties in arrays. Arrays
have a unity (what I called "one brain") at the object scale. Any
attempt we make to separate properties to a different brain will break
this unity. We can partially recover (by putting pieces of the first
brain at the property scale of the second one), but it's at the cost of
imposing non-configurable properties to be accessor properties (which,
this time, is not an invariant imposed by ES5).

The fixed property proposal (even if optional) currently imposes to
choose between no inter-property intelligence (non-configurable accessor
properties) and non-configurable property being accessors (we loose some
inter-property intelligence in that case anyway).

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

Tom Van Cutsem-3
In reply to this post by Mark S. Miller-2
2011/6/16 Mark S. Miller <[hidden email]>
Ok good, I'll take you up on that. I propose that ES-next arrays differ from ES5 arrays in that their 'length' property appears to be a non-configurable accessor property. Clearly, that better reflects the way Array's 'length' works anyway. Alternatively, if there's some problem with that, I propose that array 'length' appears to be a configurable data property that arrays nevertheless refuse to delete. Either way, proxies would then be able to emulate them faithfully.

This is also my feeling: part of the awkwardness in emulating array "length" is definitely that we're trying to mimic the behavior of an accessor property using a mutable data property. Would Mark's suggestion be too radical a change? (note: I'm not arguing for this change on the grounds of "it's too awkward to emulate using proxies". I'm arguing on the grounds of "ES5 accessor properties seem to better describe the behavior of a dynamic property such as array |length|").
 
There can't be any ES3 code that would be broken by any of these other choices, since ES3 code can't ask about these attributes.


The issue isn't only about Array length or compatibility with existing user code.  It is about whether or not Proxies have the power to implement the sort of objects that have been created in the past by host objects and implementation extensions and even the ESstandard.  What if somebody said,  I have this great new system implementation language but it has an limitation that prevents it from implementing some features of the ES standard.  Is it ok, to just get the implementation as close as I can.  That's what they would likely do regardless of what you say, but would you be happy about that?

Arrays aren't host objects. And the legacy host object behavior that WebIDL must be compat with predates ES5. To take a simple position that may be clarifying, why not have WebIDL's JS binding specify that *all* properties of host objects must be configurable? Really? This would allow host objects to do what they want within the spec, would allow proxies to emulate host objects perfectly within the spec, and would all be perfectly compat with all legacy host object behavior. I would have no objection to such a WebIDL JS-binding specification.

This isn't about how WebIDL might be modified to make it more compatible with ES, that's actually what Cameroon is trying to do right now   I see implementing ES5 built-in and implementing web app APIs are two important use cases for proxies but  I'm currently bringing those up only as specific test cases for the overall power of proxies as currently specified. Both the built-ins and current host objects exist because of loopholes that allow them to escape from the confines of normal ES native object semantics.  We want to allow metalevel programming in ES to accomplish similar things. What capabilities do we need to actually support at that metalevel?  I'm not sure.  But in the built-ins and existing browser host objects (which actually had quite wide variation across implementations) we have a fairly large corpus of what implementation have actually done at this level. I'm arguing that if we don't have the ability to replicate that corpus then we don't yet have an minimally adequate set of metalevel capabilities. 

So if all properties of host objects were configurable, would they no longer demonstrate that we don't have minimal adequacy? If we fix array 'length' as above, what remaining problem cases do we have for achieving this minimal adequacy? Can we fix these remaining problem cases in this same way?


--
    Cheers,
    --MarkM

_______________________________________________
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

Tom Van Cutsem-3
In reply to this post by David Bruant-4
Note that my idiom of turning non-configurable data props into accessor props was just that: an idiom. It's not in any way enforced by the strawman.

If one is dealing with e.g. a non-configurable data property whose [[Value]] is bound to a function, then one  can imagine a handler returning:

{ value: function(...args) { return handler.get(name)(...args); },
  writable: desc.writable,
  enumerable: desc.enumerable,
  configurable: false }

Or sometimes the handler may not even need to continue to intercept access to a property, and may just return the original descriptor.

(Also: I just updated the strawman such that the defineProperty trap would still be triggered on fixed properties, which should allow proxies + this strawman to faithfully emulate Array "length")

Cheers,
Tom

2011/6/16 David Bruant <[hidden email]>
Le 16/06/2011 00:53, Mark S. Miller a écrit :
On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[hidden email]> wrote:
 
In a way, the fixed properties proposal make proxies bicephal. For some
inputs (property names), they plug their handler-provided MOP-brain and
for some others, they plug a native object MOP-brain (ES5 - 8.12). These
brains cannot communicate. This is why changing .length in the "native
object brain" has no effect in the other brain (which handles numeric
properties(...unless some of these are non-configurable)). And I think
it has been said before, but there would be no logging possible for
non-configurable properties in the context of the fixed properties
strawman since native MOP-brain doesn't allow that.
 
Cute metaphor. But as Tom's code showed, the proxy can create fixed (non-configurable) accessor properties whose getters and setters form a corpus callosum ;).
Interactions with getter/setter is already a good thing, but I think it's not enough. ES5 offers a very fine-grained API to study objects. If we pretend to be able to emulate arrays based on proxies, we should be able to emulate everything including answering correctly when it comes to "is it a data or an accessor property descriptor?".
For instance, for a data property descriptor, even if non-configurable, "writable" can be changed from true to false (then it cannot be changed afterward). This behavior is not possible when dealing with getter/setters.
With fixed properties Tom's code, it is not possible to change an array's length from writable to not writable. Trying to do so would throw an error (because the property is non-configurable and any attempt to switch from accessor to data property descriptor throw an error (or just reject?)).

I'd like to insist on the ability for proxies to be able to emulate native arrays (and new ES5 Object.* API interaction in particular) especially because currently, SpiderMonkey has a problem with redefining ".length" on arrays. See https://bugzilla.mozilla.org/show_bug.cgi?id=598996
I wish proxies to be able to compensate if there is such a bug (in any ES implementation) and I need this level of spec conformance.
This discredits the current fixed properties proposal (especially the getter/setter compensation code), I think.

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

David Bruant-4
In reply to this post by Tom Van Cutsem-3
Le 16/06/2011 16:50, Tom Van Cutsem a écrit :
2011/6/16 Mark S. Miller <[hidden email]>
Ok good, I'll take you up on that. I propose that ES-next arrays differ from ES5 arrays in that their 'length' property appears to be a non-configurable accessor property. Clearly, that better reflects the way Array's 'length' works anyway. Alternatively, if there's some problem with that, I propose that array 'length' appears to be a configurable data property that arrays nevertheless refuse to delete. Either way, proxies would then be able to emulate them faithfully.

This is also my feeling: part of the awkwardness in emulating array "length" is definitely that we're trying to mimic the behavior of an accessor property using a mutable data property. Would Mark's suggestion be too radical a change? (note: I'm not arguing for this change on the grounds of "it's too awkward to emulate using proxies". I'm arguing on the grounds of "ES5 accessor properties seem to better describe the behavior of a dynamic property such as array |length|").
In arrays, "length" affect numerical properties, but the opposite is also true. Should all numerical properties be considered as accessors then? (there is a little bit of bad faith here, because a valid implementation is possible with just "length" being an accessor. See [1]).

Considering "length" as a data or accessor property is a secondary question in my opinion. The "magic" behavior is not at the property level but at the object level (even though it can be emulated at the property level).
The question raised by Mark is: "should objects with noticeable custom internal method (array, host objects, proxies...) be allowed to prentend having data property even if some logic is triggered under the hood?". If they are not, then, the notion of "data descriptor" does not make sense in the context of proxies because anytime a proxy could trigger any code.
Should data property descriptor be entirely banned from proxies (and host objects)?

There is a cursor to put between data and accessor properties. My opinion is that an accessor property should be used when it has a side effect *outside the object scope*. For instance, document.cookie should be an accessor, because it affects something else than the document object (namely other tabs if these send requests to the same domain). Same for element.innerHTML which triggers a reflow. However, array.length doesn't have any observable effect outside of the object it's being used on.
I am fully aware that the first flaw of this definition is that there is no way to enforce it in a program (especially not in getOwnPropertyDescriptor proxy traps return value). However, this separation may be a guideline for the spec purpose.

What are your thoughts on this separation?

David

[1] http://perfectionkills.com/how-ecmascript-5-still-does-not-allow-to-subclass-an-array/#ecmascript_5_accessors_to_the_rescue

_______________________________________________
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 Thu, Jun 16, 2011 at 8:29 AM, David Bruant <[hidden email]> wrote:
Le 16/06/2011 16:50, Tom Van Cutsem a écrit :
2011/6/16 Mark S. Miller <[hidden email]>
Ok good, I'll take you up on that. I propose that ES-next arrays differ from ES5 arrays in that their 'length' property appears to be a non-configurable accessor property. Clearly, that better reflects the way Array's 'length' works anyway. Alternatively, if there's some problem with that, I propose that array 'length' appears to be a configurable data property that arrays nevertheless refuse to delete. Either way, proxies would then be able to emulate them faithfully.

This is also my feeling: part of the awkwardness in emulating array "length" is definitely that we're trying to mimic the behavior of an accessor property using a mutable data property. Would Mark's suggestion be too radical a change? (note: I'm not arguing for this change on the grounds of "it's too awkward to emulate using proxies". I'm arguing on the grounds of "ES5 accessor properties seem to better describe the behavior of a dynamic property such as array |length|").
In arrays, "length" affect numerical properties, but the opposite is also true. Should all numerical properties be considered as accessors then? (there is a little bit of bad faith here, because a valid implementation is possible with just "length" being an accessor. See [1]).

Considering "length" as a data or accessor property is a secondary question in my opinion. The "magic" behavior is not at the property level but at the object level (even though it can be emulated at the property level).
The question raised by Mark is: "should objects with noticeable custom internal method (array, host objects, proxies...) be allowed to prentend having data property even if some logic is triggered under the hood?".

Almost, and thanks for trying to summarize. My question is

  "Should ... be allowed to pretend having a *non-configurable* data property ...?"

A perfectly fine answer to the array.length issue is to have length be a configurable data property so long as it needs to operate in a magical manner. For all such problematic magical behavior, we should likewise report the property as configurable so long as it needs to operate in a magical manner.

But as pointed out by an earlier message, my original suggestion, that array length be a non-configurable accessor, is wrong, as it would prevent it from becoming a non-configurable data property when freezing the array. So, while it's magical, either configurable data or configurable accessor would work. Once an array is frozen (or even length by itself frozen), its length no longer needs to be magical. 

In summary, all arrays, Object.defineProperty(array, 'length', {writable: true, configurable: false}) should always be rejected. Likewise for any similarly problematic properties we encounter.

 
If they are not, then, the notion of "data descriptor" does not make sense in the context of proxies because anytime a proxy could trigger any code.
Should data property descriptor be entirely banned from proxies (and host objects)?

There is a cursor to put between data and accessor properties. My opinion is that an accessor property should be used when it has a side effect *outside the object scope*. For instance, document.cookie should be an accessor, because it affects something else than the document object (namely other tabs if these send requests to the same domain). Same for element.innerHTML which triggers a reflow. However, array.length doesn't have any observable effect outside of the object it's being used on.
I am fully aware that the first flaw of this definition is that there is no way to enforce it in a program (especially not in getOwnPropertyDescriptor proxy traps return value). However, this separation may be a guideline for the spec purpose.

What are your thoughts on this separation?

David

[1] http://perfectionkills.com/how-ecmascript-5-still-does-not-allow-to-subclass-an-array/#ecmascript_5_accessors_to_the_rescue



--
    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

David Bruant-4
Le 16/06/2011 17:46, Mark S. Miller a écrit :


On Thu, Jun 16, 2011 at 8:29 AM, David Bruant <[hidden email]> wrote:
Le 16/06/2011 16:50, Tom Van Cutsem a écrit :
2011/6/16 Mark S. Miller <[hidden email]>
Ok good, I'll take you up on that. I propose that ES-next arrays differ from ES5 arrays in that their 'length' property appears to be a non-configurable accessor property. Clearly, that better reflects the way Array's 'length' works anyway. Alternatively, if there's some problem with that, I propose that array 'length' appears to be a configurable data property that arrays nevertheless refuse to delete. Either way, proxies would then be able to emulate them faithfully.

This is also my feeling: part of the awkwardness in emulating array "length" is definitely that we're trying to mimic the behavior of an accessor property using a mutable data property. Would Mark's suggestion be too radical a change? (note: I'm not arguing for this change on the grounds of "it's too awkward to emulate using proxies". I'm arguing on the grounds of "ES5 accessor properties seem to better describe the behavior of a dynamic property such as array |length|").
In arrays, "length" affect numerical properties, but the opposite is also true. Should all numerical properties be considered as accessors then? (there is a little bit of bad faith here, because a valid implementation is possible with just "length" being an accessor. See [1]).

Considering "length" as a data or accessor property is a secondary question in my opinion. The "magic" behavior is not at the property level but at the object level (even though it can be emulated at the property level).
The question raised by Mark is: "should objects with noticeable custom internal method (array, host objects, proxies...) be allowed to prentend having data property even if some logic is triggered under the hood?".

Almost, and thanks for trying to summarize. My question is

  "Should ... be allowed to pretend having a *non-configurable* data property ...?"

A perfectly fine answer to the array.length issue is to have length be a configurable data property so long as it needs to operate in a magical manner. For all such problematic magical behavior, we should likewise report the property as configurable so long as it needs to operate in a magical manner.
Currently, the "configurable" attributes has two meanings. At the same time it tells who whether or not you can delete the property and whether or not you can reconfigure (call to Object.defineProperty) your property. If I understand well, you would like it also to tell whether the property is magical or not.

If we are at a point where we'd break Object.defineProperty return values, shouldn't we add new keywords rather than adding semantics to current attribute keywords?

David

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