[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,126.96.36.199,188.8.131.52+184.108.40.206, 220.127.116.11) for such
> 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
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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss