[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Wed Jun 15 16:25:55 PDT 2011

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.

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

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

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

More information about the es-discuss mailing list