Is this-propagation as written useful?
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:
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.
Hello!
Just looking at the this-propagation stuff, and what struck me immediately is that the absolutely most desired use case to cover is not at all covered. That use case would look something like this:
Where moveLeft wants to access this.style to change the position of the element.
Another similar use case that is not covered is sending this-bound methods as callbacks.
Frankly, I think these two use cases dwarf the use cases for this-propagation with named function calls where the function name has to be a local of a shared scope. When people have questions related to scope handling and the this-value, in my experience ALL such problems stem from uses of eval, uses of Function/setTimeout/setInterval, uses of with or the various ways of doing event handlers. I've yet to see anybody posting a problem they have in this area which is actually solved by the very limited this-propagation ES4 adds, and I've been an active member in many JavaScript mailing lists and forums since before ES3 became a standard.
In my opinion, this proposal should be extended in such a way that you can actually do setTimeout(fn, delay); and have the this-value delegated. Even better if the proposal allowed setTimeout(this.fn, delay); setTimeout(a.b, delay); with the this-value set to the original this when the function was called in the first case, a in the second case.
The naive way of doing that would be to make member lookups return a delegate object remembering the parent instead of a plain function object. If called as a regular function call, it would use the delegated parent. If no such parent existed, it would use the current this-object (not the global object, unless the local this-value is the global object). I suspect doing that might be a security problem however, besides potentially breaking live scripts.
Another way might be to introduce a keyword for explicit this-delegation: setTimeout(delegate this.fn, delay); or simply a binding function: setTimeout(this.fn.bind(this), delay); or a more full-fledged delegation mechanism: setTimeout(this.fn.delegate(this,args));
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.
Hello! Just looking at the this-propagation stuff, and what struck me immediately is that the absolutely most desired use case to cover is not at all covered. That use case would look something like this: function moveLeft(){ /*...*/ } elm.onevent=function(){ setTimeout(moveLeft, delay); } Where moveLeft wants to access this.style to change the position of the element. Another similar use case that is not covered is sending this-bound methods as callbacks. Frankly, I think these two use cases dwarf the use cases for this-propagation with named function calls where the function name has to be a local of a shared scope. When people have questions related to scope handling and the this-value, in my experience ALL such problems stem from uses of eval, uses of Function/setTimeout/setInterval, uses of with or the various ways of doing event handlers. I've yet to see anybody posting a problem they have in this area which is actually solved by the very limited this-propagation ES4 adds, and I've been an active member in many JavaScript mailing lists and forums since before ES3 became a standard. In my opinion, this proposal should be extended in such a way that you can actually do setTimeout(fn, delay); and have the this-value delegated. Even better if the proposal allowed setTimeout(this.fn, delay); setTimeout(a.b, delay); with the this-value set to the original this when the function was called in the first case, a in the second case. The naive way of doing that would be to make member lookups return a delegate object remembering the parent instead of a plain function object. If called as a regular function call, it would use the delegated parent. If no such parent existed, it would use the current this-object (not the global object, unless the local this-value is the global object). I suspect doing that might be a security problem however, besides potentially breaking live scripts. Another way might be to introduce a keyword for explicit this-delegation: setTimeout(delegate this.fn, delay); or simply a binding function: setTimeout(this.fn.bind(this), delay); or a more full-fledged delegation mechanism: setTimeout(this.fn.delegate(this,args)); 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. -- David "liorean" Andersson