I'm sure this has been brought up before but my naïve searches come up empty handed so...
Is there any reason that there's no flavor of Object.seal that would throw an exception on read references to properties that are not found on the specified object? While this could be accomplished with an extra parameter on seal, for the save of this discussion I'll call it a different function: Object.lock. We've found Object.seal to be a huge aid in improving programmer productivity by catching coding errors early and preventing people from intentionally or unintentionally adding properties to objects outside the constructor. Our constructors typically add all the properties to an object and then seal it. This ensures that there's one place to see all the properties for an object and the extra cost of adding perhaps seldom used properties is won back because the shape of the object is guaranteed not to change after the constructor playing very nicely with V8 optimizations though presumably other engines would also benefit. While, of course, there are objects that don't fit this static-ish model, the bulk of them do and for those, this approach is a huge win for code maintainability. But, what still bites frequently is read references to non-existent properties which are returned as undefined. Quite often, this results in a quick exception when the undefined is used as a this and sometimes the problem is exposed as a NaN or the string "undefined" appearing in text or whatever, at which point one must backtrack to the source of the problem. The worst is when the property is used as a Boolean and undefined simply behaves as false. While I'm sure there are cases where this behavior is useful, we certainly haven't run across them and the fact that Object.seal doesn't protect against reads of non-existent properties is a complete negative. But, of course, backward-compatibility means Object.seal cannot do this. My guess is that the difficulty would lie in the prototype chain where the runtime wouldn't know that the property doesn't exist until it's at the end of the prototype chain at which point it might not have a reference to the original object. Even worse, an Object.lock might have locked some intermediate object in the prototype chain which presumably should cause an exception on a non-existent property reference. Essentially an Object.lock on any object in the prototype chain should act as a barrier to the return of undefined for non-existent properties. This would suggest an implementation where before going down the prototype chain the JS runtime would OR the lock bit in the current object with a running lock barrier bit. If it hits the end of the prototype chain and the property has not been found and the lock barrier bit is set, exception. Of course, this would add at least one extra OR for *every* prototype chain step but that doesn't seem too horrible and certainly for something like V8 with its underlying object Maps this would essentially add no overhead for the vast majority of property retrievals. And yes, this can be accomplished with a simple generic proxy but that seems like a heavyweight solution to the problem. ------ Alex Kodat Senior Product Architect Rocket Software t: +1 781 684 2294 * m: +1 315 527 4764 * w: www.rocketsoftware.com<http://www.rocketsoftware.com/> ================================ Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? Main Office Toll Free Number: +1 877.328.2932 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
