[Harmony Proxies] Proposal: Property fixing
allen at wirfs-brock.com
Wed Jun 15 10:03:24 PDT 2011
On Jun 15, 2011, at 9:40 AM, Mark S. Miller wrote:
> 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,188.8.131.52,184.108.40.206+220.127.116.11, 18.104.22.168) 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss