[Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem tomvc.be at gmail.com
Thu Jun 16 07:50:34 PDT 2011

2011/6/16 Mark S. Miller <erights at google.com>

> 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
> 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/20110616/3bf45b49/attachment.html>

More information about the es-discuss mailing list