[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Wed Jun 15 17:56:59 PDT 2011


On Wed, Jun 15, 2011 at 5:13 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

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

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110615/19030411/attachment-0001.html>


More information about the es-discuss mailing list