[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Wed Jun 15 09:40:50 PDT 2011

On Wed, Jun 15, 2011 at 9:26 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> On Jun 15, 2011, at 4:34 AM, Tom Van Cutsem wrote:
> 2011/6/14 Allen Wirfs-Brock <allen at wirfs-brock.com>
>> ...
>> I emphasize Array when I look at this simply because it is a fairly simple
>> example of the sort of thing that a host object might currently do and the
>> most important use case of proxies for me is the replacement/emulation of
>> host objects.  I really don't know where this idea that non-configurable
>> implies no special semantics comes from.  That isn't the case in the ES5
>> specification  (10.6,,, for such
>> properties.
> I'm not sure what you mean by special semantics. If you mean strong
> guarantees/invariants, then one example would be that a non-writable,
> non-configurable data property is guaranteed to have a stable value. The
> proposed strawman allows proxies to define such properties, at the expense
> of giving up interception of access to such a property.
> By "special semantics", I mean any semantics for the Object internal
> methods other than exactly what is specified in section 8.12.
> The ES specification states requirements but doesn't make any guarantees.
>  For example, it states a requirement on host objects concerning consistency
> of value for non-writable, non-configurable data properties.  But it can
> guarantee that an implementation doesn't have bugs or has simply choosen to
> ignore that requirement.   Also, the spec. doesn't say that accessing the
> value of such non-writable/non-configurable properties may not have any
> side-effects.  As far as I know, nobody has ever actually audited any of the
> emerging  ES5 browser implementations to see if their DOM implementations
> fully conform to all of the requirements of the ES5 spec. In the short term,
> I will be surprised if somebody does this and discoveres that the
> implementations all fully conform.

I don't get your point. Host objects aside, I would be surprised if any
JavaScript fully conforms to the ES5 spec in any timeframe that can be
considered short term. In both cases, when spec violations are discovered,
we hope that they get fixed. Otherwise, why have a spec at all?

> In general I see invariants violations as bugs that you normally don't
> explicitly write defensives code to detect.  You assume the invariant is
> true and expect any significant violation of the invariant to manifest
> itself in some buggy behavior of your program.  Any reasonable sized
> application or framework is gong to have hundreds, if not thousands, of such
> invariants.  I don't see why the non-writable/non-configurable invariant is
> particularly any more or less important than any other of the invariants
> that might be violated using proxies or just using regular ES code.  In
> particular, I don't understand why that invariant is so important we would
> degrade the ability to proxies to support some of their primary uses cases.
> It may be that for some security scenarios it really is important to have
> truly frozen data only objects.  I have no problem with supporting that need
> via the fix trap or something like it.  What I object to is using that use
> case as a justification for not supporting other important use cases such as
> accurate emulation of built-in objects or the DOM.
> Allen
> _______________________________________________
> 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/dd8f8ce4/attachment.html>

More information about the es-discuss mailing list