On Feb 13, 2009, at 9:44 AM, Allen Wirfs-Brock wrote:
I'm not yet convinced that this really is a significant ES3 to ES3.1 compatibility issues.
Not sure either, why I wrote "I can't prove this is going to burn programmers in the future, but I suspect it will."
I don't see that the specified behavior would be a problem for new code, written specifically to use ES 3.1 features including accessor properties and attribute manipulation. I believe that the current ES3.1 draft is complete and consistent in what will happen when those features are used in conjunction binding instantiation in Object Environment Records. New code that uses 3.1 features should expect to get 3.1 semantics.
That may not help if we make it unnecessarily hard to compose old and new code in the global object. It's an issue for existing code, and if you expect new code to use Object.getOwnPropertyDescriptor before declaring a function, just in case there's an accessor of the same name, I will bet you no one will write such code in the future, even if you staple ES3.1's spec to their foreheads.
I do think that I could probably fix the concern with some rewriting of 10.6 (Binding Instantiation) and the Environment Record interface/ implementation to ensure that functions get a "fresh" property in the binding objects. However, I'm reluctant to mess with already "debugged code", ie the specification, at this point unless this is more than a hypothetical problem.
That's fine. I'm not asking for a change, just discussion. We should implement and test.
Can anybody identify any real scenarios based upon existing implementations and existing code where this change in semantics is actually going to cause a forward compatibility problem?
Hate to say it, but you buried the important part too, for anyone not digging below the fold. But this topic isn't for short attention spans. ;-)
Laying a trap with __defineSetter__ and __defineGetter__ on the global object, to take over a function (wrap it to spy on its params), would have to depend on a failure to judge trustworthiness. But this happens (perl.com's ad supplier let its domain lapse, and pr0n.com grabbed it and hijacked location). The ES1-3 function declaration super-power of blowing away any pre-existing property provided some protection, but really, if the enemy is within the gates, you're dead.
So the more plausible threat, and a lesser one, is defending in a non- hostile case against other code that was loaded previously. Even native global bindings might be configurable and writable, for backward compatibility (undefined comes to mind, along with many DOM level 0 additions over the years). If these are all data properties, no problem. If any is an accessor, then it's hostile to existing or future code that wants to name a function with the same identifier.
Thanks for the reply, it helps to talk this stuff through (I don't have as much time to think about it as I'd like).
/be _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
