On Dec 2, 2007, at 3:07 AM, liorean wrote: > I suspect doing that might be a security problem > however, besides potentially breaking live scripts.
That's right, it's not backward compatible, so it's out. Changing runtime semantics for existing syntax under type=application/ ecmascript;version=4 just makes migration hazards of the "it seems to work, but next week we have a fire-drill due to a case that our tests didn't cover" kind. > or simply a binding function: > setTimeout(this.fn.bind(this), delay); Function.prototype.bind/Function.bind is proposed: http://wiki.ecmascript.org/doku.php?id=proposals:static_generics and it does what's wanted. Apart from extra bells and whistles that Ajax libraries add in their bind methods, it's sufficient for the case you cite, has the standard form and fit, and could be used as the more efficient basis for the elaborated bind methods in the popular libraries. > ES4's this-propagation at this moment seems to be extremely limited in > use, and specifically tailored to avoid the use cases where > this-propagation is most desired, judging from real-world problems. It seems to me your message contradicts itself. You start off asking for an incompatible change, eventually advert to the difficulties in making it, propose alternative syntax or methods, and finish by denigrating the use cases for the |this| propagation proposal. Doing so does not help make the case for an incompatible change, and only hurts those other use-cases for no clear reason. First among the use-cases addressed by the |this| proposal is the nested helper functions case, which is used in the reference implementation IIRC. This is worth fixing. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
