[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

Brendan Eich-3
On Jun 16, 2011, at 9:09 AM, David Bruant wrote:

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:

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.

Implementations need the no-delete aspect. We should not change that for Array length.

Freezing length is another use-case not to break, of course. No one disagrees there (we just have a SpiderMonkey bug to fix).


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?

We should have no more attribute "keywords" in property descriptors than we need to model the semantics we wish to reflect on via Object.* APIs and intercede in via proxies. Do we really want to split "DontDelete" back out of "configurable"?

/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
In reply to this post by David Bruant-4


On Thu, Jun 16, 2011 at 9:09 AM, David Bruant <[hidden email]> wrote:
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?

I do not believe so. The host object contract for configurable shows that the only meaning it ever had in ES5 that one could count on is "this is not guaranteed not to be magical". The proxy spec already allows the same violations of the first two meanings you suggest: 
* a proxy and a compliant ES5 host object may refuse to delete a configurable property, and 
* a proxy and a compliant ES5 host object may refuse an attempt to reconfigure a configurable property.

In summary, "configurable" was never a guarantee of anything. "non-configurable" was the only state that came with guarantees. Let's not weaken those. 



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

Mark S. Miller-2
In reply to this post by Brendan Eich-3


On Thu, Jun 16, 2011 at 9:15 AM, Brendan Eich <[hidden email]> wrote:
On Jun 16, 2011, at 9:09 AM, David Bruant wrote:

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:

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.

Implementations need the no-delete aspect. We should not change that for Array length.

Freezing length is another use-case not to break, of course. No one disagrees there (we just have a SpiderMonkey bug to fix).


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?

We should have no more attribute "keywords" in property descriptors than we need to model the semantics we wish to reflect on via Object.* APIs and intercede in via proxies. Do we really want to split "DontDelete" back out of "configurable"?

We do not. We need merely specify that (a non-frozen) array.length is configurable but that arrays refuse to delete them. This is just part of the magical length behavior provided by arrays, with the virtues that it can be faithfully emulated by proxies.


 

/be



--
    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 16, 2011, at 9:18 AM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 9:15 AM, Brendan Eich <[hidden email]> wrote:
We should have no more attribute "keywords" in property descriptors than we need to model the semantics we wish to reflect on via Object.* APIs and intercede in via proxies. Do we really want to split "DontDelete" back out of "configurable"?

We do not. We need merely specify that (a non-frozen) array.length is configurable but that arrays refuse to delete them. This is just part of the magical length behavior provided by arrays, with the virtues that it can be faithfully emulated by proxies.

Clever. To rephrase your previous reply to avoid double-negatives ("this is not guaranteed not to be magical"), "configurable properties may behave magically". I agree it's the non-configurable magic that we should address.

Bonus, I think this will simplify things in our implementation of Array length vs. the ES5 Object.* APIs.

/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 Thu, Jun 16, 2011 at 9:22 AM, Brendan Eich <[hidden email]> wrote:
On Jun 16, 2011, at 9:18 AM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 9:15 AM, Brendan Eich <[hidden email]> wrote:
We should have no more attribute "keywords" in property descriptors than we need to model the semantics we wish to reflect on via Object.* APIs and intercede in via proxies. Do we really want to split "DontDelete" back out of "configurable"?

We do not. We need merely specify that (a non-frozen) array.length is configurable but that arrays refuse to delete them. This is just part of the magical length behavior provided by arrays, with the virtues that it can be faithfully emulated by proxies.

Clever. To rephrase your previous reply to avoid double-negatives ("this is not guaranteed not to be magical"), "configurable properties may behave magically".

In retrospect, perhaps we should have named this attribute "magical" rather that "configurable"? And it is shorter. (Just kidding ;).)


 
 I agree it's the non-configurable magic that we should address.

Bonus, I think this will simplify things in our implementation of Array length vs. the ES5 Object.* APIs.

Cool! Shrinking a case explosion is often a good sign.

 

/be



--
    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
In reply to this post by Mark S. Miller-2
Le 16/06/2011 18:15, Mark S. Miller a écrit :

> I do not believe so. The host object contract for configurable shows
> that the only meaning it ever had in ES5 that one could count on is
> "this is not guaranteed not to be magical". The proxy spec already
> allows the same violations of the first two meanings you suggest:
> * a proxy and a compliant ES5 host object may refuse to delete a
> configurable property, and
> * a proxy and a compliant ES5 host object may refuse an attempt to
> reconfigure a configurable property.
>
> In summary, "configurable" was never a guarantee of anything.
> "non-configurable" was the only state that came with guarantees. Let's
> not weaken those.
Ok, with this defintion, it makes sense to not let proxies lie on
property configurability.
So does it even make sense to want non-configurable (fixed) properties
on proxies?
Back to Sean's initial e-mail on this thread, why would we want
individual non-configurable properties on proxies?

As a side note, if all properties are described as configurable, then, a
forwarding proxy will not properly forward when it comes to returning a
property descriptor if the target has a non-configurable property.

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

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



On Thu, Jun 16, 2011 at 9:09 AM, David Bruant <[hidden email]> wrote:
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?

I do not believe so. The host object contract for configurable shows that the only meaning it ever had in ES5 that one could count on is "this is not guaranteed not to be magical". The proxy spec already allows the same violations of the first two meanings you suggest: 
* a proxy and a compliant ES5 host object may refuse to delete a configurable property, and 
* a proxy and a compliant ES5 host object may refuse an attempt to reconfigure a configurable property.

In summary, "configurable" was never a guarantee of anything. "non-configurable" was the only state that came with guarantees. Let's not weaken those. 

I don't agree with this conclusion at all.  There is a guarantee, it is just hard to know when it is applicable. 

There are three layers of the system invoked here:

1) The normal native object semantics as manifest in the basic native operations of the language: property put, property get, property delete, implicitly or declarative property create, property enumerate, etc.  This is the level that most application code operates at.

2) The Object.* introspection semantics that  provide information (attribute values) on and limited control  of how individual properties will actually respond to the basic native object operations.  

3) An intercession semantics that allows complete redefinition of the semantics of the basic object operations.  This is the "magic" level that allows creation of things that aren't normal native objects.  This level includes the mechanisms of Proxy, host objects, and any built-in object semantics that deviate from normal object semantics.

For  normal native objects there is a complete specification of the relationship between layer 1 and layer 2.  For example, if you inspect a property's configurable attribute (a level to reflection operation) and see that its value is true you know that applying the delete operator to that property  (a level 1 operation will succeed in deleting the property).  Similarly if you use a reflective operation to set the configurable attribute of a property you know that applying a delete operation will fail.

The root question here seems to be if and how level 3 is allowed to modify the standard semantic linkage between levels 1 and 2. Given that level 3 is permitted to make pretty much arbitrary changes to the level 1 semantics, I'm not sure that this is even a very meaningful question as the level 1/level 2 normal native object semantic coupling is dependent upon the normal level 1 semantics.  ES5 tried to express some restrictions  upon what host objects are allowed WRT the level 1-2 semantic linkage. Those restriction had no teeth and it isn't clear that they have had any impact. There were no such restrictions on additional implementation provided built-in objects.  We are now talking about what restriction are imposed (and enforced) on Proxy based objects.

Given the above view, it seems pointless to argument about placing level 3 constraints upon the value of the configurable attribute so that level 1 (or level 2) code can condition its behavior based upon its setting.  What such code really want to know is whether an object is a native object and hence conforms to the standard level 1 and level 2 semantics or whether this is a magic level 3 defined object.  In the latter case, no logic based upon the native object semantics will necessarily be valid.  It seems that what such code really needs is the ability to test whether or not an object is a magic object.  If not, it can depend upon the native object semantics for both level 1 and level 2.  If it is magic, the client code might refuse to deal with the object or it might attempt to further identify the specific spell that the object is under in order to understand how it will behave.

Allen









--
    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
In reply to this post by David Bruant-4


On Thu, Jun 16, 2011 at 10:13 AM, David Bruant <[hidden email]> wrote:
Le 16/06/2011 18:15, Mark S. Miller a écrit :
> I do not believe so. The host object contract for configurable shows
> that the only meaning it ever had in ES5 that one could count on is
> "this is not guaranteed not to be magical". The proxy spec already
> allows the same violations of the first two meanings you suggest:
> * a proxy and a compliant ES5 host object may refuse to delete a
> configurable property, and
> * a proxy and a compliant ES5 host object may refuse an attempt to
> reconfigure a configurable property.
>
> In summary, "configurable" was never a guarantee of anything.
> "non-configurable" was the only state that came with guarantees. Let's
> not weaken those.
Ok, with this defintion, it makes sense to not let proxies lie on
property configurability.
So does it even make sense to want non-configurable (fixed) properties
on proxies?
Back to Sean's initial e-mail on this thread, why would we want
individual non-configurable properties on proxies?

As a side note, if all properties are described as configurable, then, a
forwarding proxy will not properly forward when it comes to returning a
property descriptor if the target has a non-configurable property.

As far are I can tell, the only reason anyone is asking for non-configurable properties on trapping proxies is the issue raised by your side note. But for this issue, I see no need to allow fixing of individual properties on trapping proxies.


 

David



--
    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 16, 2011, at 11:26 AM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 10:13 AM, David Bruant <[hidden email]> wrote:
Le 16/06/2011 18:15, Mark S. Miller a écrit :
> In summary, "configurable" was never a guarantee of anything.
> "non-configurable" was the only state that came with guarantees. Let's
> not weaken those.
Ok, with this defintion, it makes sense to not let proxies lie on
property configurability.
So does it even make sense to want non-configurable (fixed) properties
on proxies?
Back to Sean's initial e-mail on this thread, why would we want
individual non-configurable properties on proxies?

As a side note, if all properties are described as configurable, then, a
forwarding proxy will not properly forward when it comes to returning a
property descriptor if the target has a non-configurable property.

As far are I can tell, the only reason anyone is asking for non-configurable properties on trapping proxies is the issue raised by your side note. But for this issue, I see no need to allow fixing of individual properties on trapping proxies.

There is a second reason, mentioned recently: we are implementing the DOM on top of proxies, and the current WebIDL spec has non-configurable properties induced in its normative ES bindings from the IDL syntax. We want to match the 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

Mark S. Miller-2


On Thu, Jun 16, 2011 at 4:05 PM, Brendan Eich <[hidden email]> wrote:
On Jun 16, 2011, at 11:26 AM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 10:13 AM, David Bruant <[hidden email]> wrote:
Le 16/06/2011 18:15, Mark S. Miller a écrit :
> In summary, "configurable" was never a guarantee of anything.
> "non-configurable" was the only state that came with guarantees. Let's
> not weaken those.
Ok, with this defintion, it makes sense to not let proxies lie on
property configurability.
So does it even make sense to want non-configurable (fixed) properties
on proxies?
Back to Sean's initial e-mail on this thread, why would we want
individual non-configurable properties on proxies?

As a side note, if all properties are described as configurable, then, a
forwarding proxy will not properly forward when it comes to returning a
property descriptor if the target has a non-configurable property.

As far are I can tell, the only reason anyone is asking for non-configurable properties on trapping proxies is the issue raised by your side note. But for this issue, I see no need to allow fixing of individual properties on trapping proxies.

There is a second reason, mentioned recently: we are implementing the DOM on top of proxies, and the current WebIDL spec has non-configurable properties induced in its normative ES bindings from the IDL syntax. We want to match the spec.

Perhaps the WebIDL spec should be revised in exactly the same we we're currently talking about revised arrays?

 

/be




--
    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 16, 2011, at 4:14 PM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 4:05 PM, Brendan Eich <[hidden email]> wrote:
There is a second reason, mentioned recently: we are implementing the DOM on top of proxies, and the current WebIDL spec has non-configurable properties induced in its normative ES bindings from the IDL syntax. We want to match the spec.

Perhaps the WebIDL spec should be revised in exactly the same we we're currently talking about revised arrays?

It's in Last Call, so time is short. Also, implementations do matter, and non-configurable is valued by implementations that want to optimize by assuming the slot in the object won't go away. If we make Array length, NodeList length, etc. be configurable, we implementors will need some *other* hidden attribute.

/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 Thu, Jun 16, 2011 at 4:23 PM, Brendan Eich <[hidden email]> wrote:
On Jun 16, 2011, at 4:14 PM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 4:05 PM, Brendan Eich <[hidden email]> wrote:
There is a second reason, mentioned recently: we are implementing the DOM on top of proxies, and the current WebIDL spec has non-configurable properties induced in its normative ES bindings from the IDL syntax. We want to match the spec.

Perhaps the WebIDL spec should be revised in exactly the same we we're currently talking about revised arrays?

It's in Last Call, so time is short. Also, implementations do matter, and non-configurable is valued by implementations that want to optimize by assuming the slot in the object won't go away. If we make Array length, NodeList length, etc. be configurable, we implementors will need some *other* hidden attribute.

There is already internal special case handling for every property that needs to be magical. So having non-delete-ability be part of this special case handling would seem natural. From your 

Bonus, I think this will simplify things in our implementation of Array length vs. the ES5 Object.* APIs.

it might even be net more natural than the current situation.
 

/be




--
    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 16, 2011, at 4:27 PM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 4:23 PM, Brendan Eich <[hidden email]> wrote:
On Jun 16, 2011, at 4:14 PM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 4:05 PM, Brendan Eich <[hidden email]> wrote:
There is a second reason, mentioned recently: we are implementing the DOM on top of proxies, and the current WebIDL spec has non-configurable properties induced in its normative ES bindings from the IDL syntax. We want to match the spec.

Perhaps the WebIDL spec should be revised in exactly the same we we're currently talking about revised arrays?

It's in Last Call, so time is short. Also, implementations do matter, and non-configurable is valued by implementations that want to optimize by assuming the slot in the object won't go away. If we make Array length, NodeList length, etc. be configurable, we implementors will need some *other* hidden attribute.

There is already internal special case handling for every property that needs to be magical. So having non-delete-ability be part of this special case handling would seem natural. From your 

Bonus, I think this will simplify things in our implementation of Array length vs. the ES5 Object.* APIs.

it might even be net more natural than the current situation.

My "Bonus" remark was *only* about Array length. For a great number of non-configurable properties (e.g. global vars in ES5 implementations, not created by eval), we JIT authors need a general attribute to consult. We aren't hardcoding, as we do for Array length (all the fast VMs optimize a.length expressions in the dense array, or any array, case).

/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 Thu, Jun 16, 2011 at 4:30 PM, Brendan Eich <[hidden email]> wrote:
On Jun 16, 2011, at 4:27 PM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 4:23 PM, Brendan Eich <[hidden email]> wrote:
On Jun 16, 2011, at 4:14 PM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 4:05 PM, Brendan Eich <[hidden email]> wrote:
There is a second reason, mentioned recently: we are implementing the DOM on top of proxies, and the current WebIDL spec has non-configurable properties induced in its normative ES bindings from the IDL syntax. We want to match the spec.

Perhaps the WebIDL spec should be revised in exactly the same we we're currently talking about revised arrays?

It's in Last Call, so time is short. Also, implementations do matter, and non-configurable is valued by implementations that want to optimize by assuming the slot in the object won't go away. If we make Array length, NodeList length, etc. be configurable, we implementors will need some *other* hidden attribute.

There is already internal special case handling for every property that needs to be magical. So having non-delete-ability be part of this special case handling would seem natural. From your 

Bonus, I think this will simplify things in our implementation of Array length vs. the ES5 Object.* APIs.

it might even be net more natural than the current situation.

My "Bonus" remark was *only* about Array length. For a great number of non-configurable properties (e.g. global vars in ES5 implementations, not created by eval), we JIT authors need a general attribute to consult. We aren't hardcoding, as we do for Array length (all the fast VMs optimize a.length expressions in the dense array, or any array, case).

Can we gather a list of all magical host properties that WebIDL says are currently non-configurable but that proxies can't emulate unless they are made configurable?


--
    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 16, 2011, at 4:32 PM, Mark S. Miller wrote:

My "Bonus" remark was *only* about Array length. For a great number of non-configurable properties (e.g. global vars in ES5 implementations, not created by eval), we JIT authors need a general attribute to consult. We aren't hardcoding, as we do for Array length (all the fast VMs optimize a.length expressions in the dense array, or any array, case).

Can we gather a list of all magical host properties that WebIDL says are currently non-configurable but that proxies can't emulate unless they are made configurable?

See the recent public-script-coord threads -- but I'm not sure enumerating cases will help.  We do not want to hardcode a list, even if short. Array length, we hardcode for competitive reasons; that cost is mostly sunk (and there's no sunk cost fallacy that I can see, just details about how one optimizes arrays).

For any more general set of non-configurable properties, we want one bit to condition judgment about how sealed or frozen the property is. We want this from JIT code, and also for deciding whether it is safe to share deeply frozen objects across threads via workers.

/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 Brendan Eich-3
Le 17/06/2011 01:23, Brendan Eich a écrit :
On Jun 16, 2011, at 4:14 PM, Mark S. Miller wrote:

On Thu, Jun 16, 2011 at 4:05 PM, Brendan Eich <[hidden email]> wrote:
There is a second reason, mentioned recently: we are implementing the DOM on top of proxies, and the current WebIDL spec has non-configurable properties induced in its normative ES bindings from the IDL syntax. We want to match the spec.

Perhaps the WebIDL spec should be revised in exactly the same we we're currently talking about revised arrays?

It's in Last Call, so time is short. Also, implementations do matter, and non-configurable is valued by implementations that want to optimize by assuming the slot in the object won't go away. If we make Array length, NodeList length, etc. be configurable, we implementors will need some *other* hidden attribute.
I think that the deeper question we have to deal with now is the exact semantics of configurability when it comes to "non-natural objects" (array, host objects, proxies. Is there an official name for them in the spec?).
My understanding is that Allen seems to question the applicability/application/ground of the spec on that ("Those restriction had no teeth and it isn't clear that they have had any impact.").

Currently, ES5 - 8.6.2 says:
"The [[GetOwnProperty]] internal method of a host object must conform to the following invariants for each property of the host object:
(...five bullets points...)"
I'd like to ask a few questions on this part of the spec:
Why are we expecting anything from host (all if including arrays?) objects at all? (I know this one is naive and a bit provocative, but I actually wonder)
Why are we expecting host (all if including arrays?) objects to respect these particular invariants (this is actually 5 questions) and no other?

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

Cameron McCormack-4
In reply to this post by Mark S. Miller-2
Hi Mark.

Mark S. Miller:
> Can we gather a list of all magical host properties that WebIDL says are
> currently non-configurable but that proxies can't emulate unless they are
> made configurable?

Web IDL requires various properties to be non-configurable, but the ones
we care about here are just the ones that need to exist on objects that
will have to be implemented using proxies, right?  I believe that list
is only:

  1. the length own property on array host objects
  2. each array index own property on an array host object

Constants map to non-configurable properties, but they exist only on
interface objects and interface prototype objects, which are “normal”
objects that wouldn’t need to be implemented using proxies.


I will soon commit (probably today) a change to make indexed/named
properties be exposed using custom [[GetOwnProperty]] and
[[DefineOwnProperty]] handlers, which will mean objects that support
indexed/named properties need to be proxies.  The relevant issue with
these is that these objects must also expose non-configurable properties
that users set on them.  For example:

  <!DOCTYPE html>
  <form name=a></form>
  <script>
    var forms = document.getElementsByTagName("form");
    Object.defineOwnProperty(forms, "z", { value: 1 });
  </script>

forms needs to expose two properties, "0" and "a", whose values are the
HTMLFormElement.  In my upcoming change, [[GetOwnProperty]] will be
specified to return this property descriptor for property "0":

  { [[Writable]]:false, [[Enumerable]]:true, [[Configurable]]:true,
    [[Value]]:theHTMLFormElement }

but to refuse to allow the property to be reconfigured.

It would be nice if the z property could be allowed to be defined and
exposed as a non-configurable property, but this can’t be done without
the proxy proposal changes being discussed here.  But I don’t think it’s
a huge loss if we just disallow non-configurable properties from being
set on objects that support indexed/named properties.  My plan was to
silently make [[DefineOwnProperty]] for such objects assume
[[Configurable]] was true on the descriptor it receives.  Throwing would
also be acceptable.


We could do the same thing for the array host objects mentioend at the
top of the email, too: have the length and individual array index
properties be reported as configurable, but to have
[[DefineOwnProperty]] refuse to reconfigure them.

--
Cameron McCormack ≝ http://mcc.id.au/
_______________________________________________
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

Cameron McCormack-4
In reply to this post by Mark S. Miller-2
(BTW, Web IDL is not in Last Call right now, but it is close.)

One question I forgot to ask, which is just my ignorance about the
details of the proxy proposal.  Say you have a prototype chain like
this:

  [object a] → [object b] → [Object prototype object] → null

a is a proxy object and b is a normal object.  If you define a non-
configurable property on b, and you look up that property on a, can it
still be reported as non-configurable?

--
Cameron McCormack ≝ http://mcc.id.au/
_______________________________________________
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 David Bruant-4
On Thu, Jun 16, 2011 at 4:54 PM, David Bruant <[hidden email]> wrote:
I think that the deeper question we have to deal with now is the exact semantics of configurability when it comes to "non-natural objects" (array, host objects, proxies. Is there an official name for them in the spec?).

Allen and I just had a long phone conversation about these issues. We ended up speaking in terms of a three part distinction:

* normal native objects, i.e., those native objects or functions whose internal methods operate in the normal non-magical way. Normal native functions includes both built-in functions (e.g. Object.prototype.valueOf) and functions written in JavaScript (e.g., what "function(){}" evaluates to).

* abnormal native objects, like arrays, whose internal methods are still fully specified by the ES5 spec, but whose behavior is peculiar / magical.

* non-native objects, i.e., "host objects". We started our conversation with a long digression into spec legalese about whether an object could be neither native nor host. I still take the position that there cannot be by definition. I don't know whether Allen ended up agreeing. But we agreed that there are not currently any such taxonomy breaking objects, and so for our purposes we could use "non-native" and "host" as synonyms. "non-native" is less confusing since it avoids tempting one into inventing a fourth category.

In ES6, proxies create an open ended set of abnormal native objects whose behavior is defined by JavaScript code. To ES5 code in an ES6 environment, such proxies are non-native, in that their ES5-level behavior is not fully specified by the ES5 spec.

 
My understanding is that Allen seems to question the applicability/application/ground of the spec on that ("Those restriction had no teeth and it isn't clear that they have had any impact.").


NOTE: I offer the following only as a concrete example of a more general point, rather than to single out Safari. There are plenty of irritating spec violations across all the major browsers. But the following is a particularly clear example.


Currently, on Safari WebKit Nightly Version 5.0.5 (5533.21.1, r88920) and on Chrome 13.0.782.24 dev

    (1,{}.valueOf)()

evaluates to the global object, in violation of the ES5 spec. (This is fixed as of Chrome 14.0.794.0 dev.) Although I reported <https://bugs.webkit.org/show_bug.cgi?id=51097> in December 2010, WebKit still lists this bug as UNCONFIRMED.

Possible conclusion from this: the ES5 spec has no teeth and it isn't clear that it has any impact. My conclusion instead is that we're still in early days at rolling specs into tests that pressure implementors to conform. But when implementors violate clear spec language, we should report these violations, ensure that these violations show up as violations in standard test suites, and pressure implementors to eventually conform. 


 

Currently, ES5 - 8.6.2 says:
"The [[GetOwnProperty]] internal method of a host object must conform to the following invariants for each property of the host object:
(...five bullets points...)"
I'd like to ask a few questions on this part of the spec:
Why are we expecting anything from host (all if including arrays?) objects at all? (I know this one is naive and a bit provocative, but I actually wonder)

Because it's in the spec, and we should all ensure that any violations of the spec stand out like a sore thumb in standard test suites.

 
Why are we expecting host (all if including arrays?) objects to respect these particular invariants (this is actually 5 questions) and no other?

Because these invariants are in the spec.

Put another way, do you expect Safari to eventually fix the December "valueOf" bug they haven't yet even confirmed? Why?

Should we ever stop expecting anyone to pay attention to the spec, I suggest that TC39 disband.


Another useful line of question is: Why are these invariants in the spec? This is useful to discuss, but is a separate matter.



David



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

Mark S. Miller-2
In reply to this post by Cameron McCormack-4


On Thu, Jun 16, 2011 at 5:11 PM, Cameron McCormack <[hidden email]> wrote:
Hi Mark.

Mark S. Miller:
> Can we gather a list of all magical host properties that WebIDL says are
> currently non-configurable but that proxies can't emulate unless they are
> made configurable?

Web IDL requires various properties to be non-configurable, but the ones
we care about here are just the ones that need to exist on objects that
will have to be implemented using proxies, right?

Yes. And of those, only the ones that need to have magical behavior that violates the invariants associated with non-configurability. IIUC, this exempts WebIDL constants, as they never violate those invariants, no matter how weird their host object. Is this right?

 
 I believe that list
is only:

 1. the length own property on array host objects
 2. each array index own property on an array host object

By "array host objects", do you mean, for example, NodeList? Is there a general definition of "array host object"?

I expect that "length" on array host objects should be treated however we treat "length" on regular arrays. Does this seem reasonable?

Why do array index own properties of array host objects need to be non-configurable? What would be lost if these were non-configurable but array host objects could refuse to delete them?

 

Constants map to non-configurable properties, but they exist only on
interface objects and interface prototype objects, which are “normal”
objects that wouldn’t need to be implemented using proxies.

Great! But as I mention above, I don't think these would be problematic in any case. 


I will soon commit (probably today) a change to make indexed/named
properties be exposed using custom [[GetOwnProperty]] and
[[DefineOwnProperty]] handlers, which will mean objects that support
indexed/named properties need to be proxies.  The relevant issue with
these is that these objects must also expose non-configurable properties
that users set on them.  For example:

 <!DOCTYPE html>
 <form name=a></form>
 <script>
   var forms = document.getElementsByTagName("form");
   Object.defineOwnProperty(forms, "z", { value: 1 });
 </script>

forms needs to expose two properties, "0" and "a", whose values are the
HTMLFormElement.  In my upcoming change, [[GetOwnProperty]] will be
specified to return this property descriptor for property "0":

 { [[Writable]]:false, [[Enumerable]]:true, [[Configurable]]:true,
   [[Value]]:theHTMLFormElement }

but to refuse to allow the property to be reconfigured.

Great! So long as this property claims to be configurable, it raises none of these issues.

 

It would be nice if the z property could be allowed to be defined and
exposed as a non-configurable property, but this can’t be done without
the proxy proposal changes being discussed here.

I'm curious why you think this would be nice?

 
 But I don’t think it’s
a huge loss if we just disallow non-configurable properties from being
set on objects that support indexed/named properties.  My plan was to
silently make [[DefineOwnProperty]] for such objects assume
[[Configurable]] was true on the descriptor it receives.  Throwing would
also be acceptable.

This is great! It looks like our hard issues are rapidly dissolving away.


We could do the same thing for the array host objects mentio[ne]d at the
top of the email, too: have the length and individual array index
properties be reported as configurable, but to have
[[DefineOwnProperty]] refuse to reconfigure them.

This is really awesome and much appreciated. Thanks for the clarifications!

 

--
Cameron McCormack ≝ http://mcc.id.au/



--
    Cheers,
    --MarkM

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