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