Deprecate jQuery.proxy #2958
Deprecate jQuery.proxy #2958
Comments
It's used extensively to call prototype functions with context for event bindings in many jquery plugins, notably in bootstrap's plugins. I don't think it should be deprecated, though its easy enough to roll your own. |
Proposal here for deprecation only, not for removal, if it would be removed, it would happen in major version. As you said you it is easy to supplement, which what jquery-migrate would do anyway |
It's small enough that if it's getting wide usage, I don't see the need for deprecation. |
One thing that jQuery.proxy does and Function#bind doesn't is setting guid
on the bound function instances so that proxied event handlers can be
removed without storing the instance of the proxied function.
|
@timmywil would you recommend to use |
@markelog I still use proxy over bind when I think it's cleaner to pass a function name rather than the function. |
If we still recommend to use But i don't think that refusal from deprecation should came from "used a lot" place, if that is the only reason, then we should discourage people from using it, which is what deprecation is, which doesn't mean we would need to remove it at 4.0, it could be the next or next after next. |
Carrying over our discussion about breaking things from yesterday's meeting, it seems like there is not a lot of benefit from deprecating this or eventually removing it. It isn't a lot of code inside jQuery and removing it will just make someone rewrite code that works perfectly well today. That's in contrast to something like the Deferred changes which, although potentially more disruptive, are driven by our desire to align with Promise standards. I started this wiki page that's similar to our Adding page where we can try to outline our practices. |
Deprecating in favour |
Precisely |
If we put a deprecation warning in Migrate about it, people will feel compelled to get rid of that warning or complain to us about it. If we have a schedule for removal that makes sense, but if it's eternal deprecation I don't know if it does. |
Yeah, that would be consequences of deprecation, also adding note about deprecation to the documentation. Frankly, i'm not sure why we wouldn't want to promote |
Then don't put a warning in migrate. |
I only want to deprecate things that are slated for eventual removal. I'm fine promoting |
If no one would used because we discourage it, it would be logical to eventually remove it, besides definition of deprecation is -
What term do you prefer? |
Why? Also what Oleg said. |
Im guessing Im not understanding something obvious, and this may be a really dumb question, but Im wondering if native bind can be used to stub $.proxy when it's available. Calling proxied functions is roughly 80% slower than calling the same function using bind. In Firefox it was 114% slower. |
We've deprecated this method, so we aren't planning to do any other implementation. |
@dmethvin Did you close it by accident? We haven't deprecated it yet so I'll reopen... |
It seems their use is mostly fulfilled with
Function#bind
and other signatures has limited useThe text was updated successfully, but these errors were encountered: