On Jun 15, 2011, at 9:40 AM, Mark S. Miller wrote: > > > On Wed, Jun 15, 2011 at 9:26 AM, Allen Wirfs-Brock <[email protected]> > 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 > 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? >
Reason for restricting the configurable attribute of properties of Proxy objects seems to be trading off an attempt to guarantee an resonable invariant but at the cost of limiting the utility of proxies. My point is that such guarantees are never more than requirements that may or may not be met by actual implementations. If the requirement is there for security reasons then it probably isn't enough for you to blindly depend upon it. Given that, I don't see why proxies should be partially crippled in a attempt to turn a requirement into a guarantee. I'm fine with stating a requirement for proxy implementors just like we do for host object implementors. I'm not fine with it being a lynchpin of enforced proxy semantics. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
