<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 19, 2012, at 10:04 AM, Tom Van Cutsem wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">Hi Allen,</div><div class="gmail_quote"><br></div><div class="gmail_quote">2012/11/18 Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The proxy spec.for Object.getOwnPropertyNames/kets/etc. seem to be doing quite a bit more than this. They</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
1) always copy the array returned from the trap?  Why is this necessary?  Sure the author of a trap should probably always return a fresh object but not doing so doesn't violate the integrity of the frozen/sealed invariants?  In most cases they will provide a fresh object and  copying adds unnecessary  work  that is proportional to the number of names to every such call.<br>
</blockquote><div><br></div><div>The copying is to ensure:</div><div>a) that the result is an Array</div></div></blockquote><div><br></div><div>Why is Array-ness essential?  It was what ES5 specified, but ES5 had a fixed implementations of Object.getOwnPropertyNames/keys so that requirement was simply a reflection of what the  spec's algorithms actually did.  Most places in the specification that consume an "array" only require array-like-ness, not an actual array.  Now that we're make the implementation of the getOPN/keys extensible, it would be natural to relax the requirement that they produce a  [[Class]]==="Array" object.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>b) that all the elements of the result are Strings</div></div></blockquote><div><br></div><div>And presumably Symbols.  We have to also accommodate Symbols, at least for getOwnPropetyNames.  Regardless, why is this important?  More below...</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>c) to ensure the stability of the result.</div><div>
<br></div><div>You can think of a + b as implementing a type coercion of the trap result to "Array of String". This coercion is not too dissimilar from what the getOwnPropertyDescriptor has to do (normalization of the returned property descriptor by creating a fresh copy).</div></div></blockquote><div><br></div><div>Yes, premature type coercion, in my opinion. Also, a classic performance mistakes made by dynamic language programmers:  unnecessary coercion of values that are never going to be access or redundant coercion checks of values that are already of the property type.  Why is it important to do such checks on values that are are just passing through these traps.  When and if somebody actually gets arounds to using one of the elements that are returned as a property key they will be automatically coerced to a valid value.  Why is it important that it happens any sooner than that.</div><div><br></div><div>getOwnPropertyDescriptor is also on my list to talk to you about for similar reasons.  I don't see why the property descriptor needs to be normalized and regenerated (including converting accessor properties on the descriptor into data properties and requiring the [[Prototype]] to be object.  I have an alternative for [[GetOwnProperty]]/TrapGetOwnPropertyDescriptor that preserves the original object returned from the trap (while normalizing to a descriptor record for any internal calls on ordinary objects).  This preserves any exotic property descriptor object properties as is.  This seems like exactly the right things.  Such exotic property descriptor properties can only be meaningfully used by other proxy traps or application/library code that knows about them.  I don't see any need to normalize them into data properties or otherwise muck with what the actually implementor of the getOwnPropertyDescrptor trap choose to return. </div><div><br></div><div>I this alternative implementation is, again, much simpler (and efficient) with fewer externally observable calls in its algorithm steps.  I sure you will want to review it so I will include it in the spec. draft.</div><div><br></div><blockquote type="cite"><div class="gmail_quote">
<div><br></div><div>c) on the other hand is crucial for the non-configurability/non-extensibility checks mentioned below. It's no use checking some invariants on a data structure if that data structure can later still be mutated.</div></div></blockquote><div>I don't see how an extra copy of the the result array makes any difference in this regard  (also see below).   The array returned from Object.getOwnPropertyNames is still mutable even after you make a copy. It's only as stable as any other non-frozen object you are likely to encounter. </div><div><br></div><div><br></div><blockquote type="cite"><div class="gmail_quote">
<div><br></div><div>If we don't care about any of a, b and c, then the result array wouldn't need to be copied.</div></div></blockquote>yes, I believe that should be the case.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) ensuring that the list of property keys contains no duplicates.  Why is this essential?  Again, I don't see what it has to do with the integrity of the frozen/sealed invariants.  It is extra and probably unnecessary work that is at least proportional to the number of names).<br>
</blockquote><div><br></div><div>We've been going back and forth over whether or not we wanted to prevent duplicates. I remember Andreas Gal being concerned about these kinds of issues (that was when he was doing the first Firefox prototype for old proxies, in the context of the enumerate() trap, which was called during a live for-in loop. IIRC, Firefox already did de-dupe checks, as properties already enumerated in a child object should not be re-visited when visiting a parent object)</div>
<div><br></div><div>More recently, at the last TC39 meeting in Boston, we decided to change the return type of the enumerate() trap from Array[String] to Iterator, and in doing so waiving the duplicate properties check. Quoting from the "Open issues" section of <<a href="http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies#open_issues">http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies#open_issues</a>>:</div>
<div><br></div><div><div>"Enumerate trap signature: consider making the enumerate() trap return an iterator rather than an array of strings. To retain the benefits of an iterator (no need to store collection in memory), we might need to waive the duplicate properties check. Resolution: accepted (duplicate properties check is waived in favor of iterator return type)"</div>
</div><div><br></div><div>I guess if duplicate properties are not crucial for enumeration, they're also not crucial for Object.getOwnPropertyNames and Object.keys and can be dropped. Mark, can you comment?</div></div></blockquote><div><br></div>good<br><blockquote type="cite"><div class="gmail_quote"><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">3) Every name in the list returned by the trap code is looked up on the target to determine whether or not it exists, even if the target is extensible.   Each of those lookup is observable (the target might itself be a proxy) so, according to the algorithm they all must be performed.<br>
</blockquote><div><br></div><div>This is where we get into actual checks required to enforce non-configurability/non-extensibility.</div><div><br></div><div>Granted, the ES5 spec is not clear about the invariants on getOwnPropertyNames and keys. The currently specified invariants are a common-sense extrapolation of the existing invariants to cover these operations.</div></div></blockquote><div><br></div><div>Yes, but if they aren't essential then we have to take into account the cost of doing non-essential invariant checks.  These costs are both the actual runtime cost of doing the checks, the constraints upon implementation imposed by the need for complete and properly sequenced occurrence of all potentially externally observable algorithm steps, and finally (and least important) the added complexity of the specification which makes it harder to actually achieve interoperable implementations. </div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div><br></div><div>In practice, it determines the degree of confidence that a programmer can have in Object.getOwnPropertyNames and friends when dealing with a frozen object. If we waive these invariant checks, then the result of those operations can never be trusted on to reliably introspect on a frozen object's list of property names:</div>
<div><br></div><div>Object.isFrozen(proxy) // true</div><div>Object.getOwnPropertyNames(proxy) // ['foo']</div><div>Object.getOwnPropertyNames(proxy) // [ ]</div><div><br></div><div>Here, the 'foo' property apparently disappeared on a frozen object.</div></div></blockquote><div><br></div><div>Yes, but copying the result an extra time doesn't ensure that two separate calls produce the same result. </div><div><br></div><blockquote type="cite"><div class="gmail_quote">
<div><br></div><div>If neither the for-in loop nor Object.getOwnPropertyNames nor Object.keys can reliably report an object's own properties, then we've made it impossible to reliably traverse and inspect a presumably deep-frozen object graph.</div></div></blockquote><div><br></div><div>If that is the goal, that maybe what you need is a new operation that cannot be trapped.  Your algorithm is essentially doing all the work, and more, necessary to generate an accurate report of the actual non-configurable properties of the target.  If that is what is needed for your deep frozen traversals, add that operation.  That seems better than allowing the Proxy trap to do the work to report anything it wants, but then coming in after the fact and checking whether what was report matches what you demand.  In this case, it seems preferable to just provide the results you demand without any handler intervention. </div><div><br></div><div>This seems to harken back to the original proxy design that essentially turned frozen objects into regular objects with no handlers. If that is what you need, you should provide access to the results you need for the situations where you need them.</div><div><br></div><div>But you should not be adding this overhead for Proxy uses that don't have those requirements.</div><div><br></div><div><br></div><blockquote type="cite"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4) Every own property of the target, is observably looked up (possibly a second time) even if the object is extensible  and has no non-configurable properties.<br>
</blockquote><div><br></div><div>We may be able to remove the redundancy of two lookups by restructuring the algorithm.</div><div>There previously was some redundancy in other checks as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It isn't clear to me if any of this work is really necessary to ensure integrity.  After all, what can you do with any of these names other than use them as the property key argument to some other trap/internal method such as [[SetP]], [[DefineOwnProperty]], etc.  Called on a proxy, those fundamental operations are going to enforce the integrity invariants of the actual properties involved so the get name checks doesn't really seem to be adding anything essential.<br>

<br>
Perhaps we can just get rid of all the above checking.  It seems like a good idea to me.<br>
<br>
Alternatively,  it suggests that a [[GetNonConfigurablePropertyNames]] internal method/trap would be a useful call to have as the integrity invariants only care about non-configurable properties. That would significantly limit the work in the case where there are none and limit the observable trap calls to only the non-configurable properties.<br>
</blockquote><div><br></div><div>That would be one way to speed things up.</div><div><br></div><div>I share your concern that the current spec algorithm may be a bit too restrictive for implementations to allow optimizations. It's very imperative. We should ask the spec implementors to have a look at the draft spec and share their concerns.</div></div></blockquote><div><br></div>Maybe we should move this discussion to es-discuss.  What do you think?</div><div><br></div><div>Allen<br><blockquote type="cite"><div class="gmail_quote">
<div><br></div><div>Cheers,</div><div>Tom</div></div>
</blockquote></div><br></div></body></html>