typo in 3rd sentence of 2nd paragraph: "can guarantee" --> "can't guarantee"
On Jun 15, 2011, at 9:26 AM, Allen Wirfs-Brock wrote: > > On Jun 15, 2011, at 4:34 AM, Tom Van Cutsem wrote: > >> 2011/6/14 Allen Wirfs-Brock <[email protected]> >> ... >> >> 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,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) 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't > 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. > > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
