[Harmony Proxies] Proposal: Property fixing

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Jun 15 17:13:59 PDT 2011


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

> On Wed, Jun 15, 2011 at 4:01 PM, Brendan Eich <brendan at mozilla.com> wrote:
> On Jun 15, 2011, at 3:53 PM, Mark S. Miller wrote:
> 
>> On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <david.bruant at labri.fr> 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 <allen at wirfs-brock.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110615/ee881f67/attachment-0001.html>


More information about the es-discuss mailing list