Uh oh!
There was an error while loading. Please reload this page.
sys: Remove after 3 years of deprecation - #182
Conversation
bnoordhuis
commented
Dec 20, 2014
Everyone: thoughts on this? Anecdotal: I still see code from time to time that uses the sys module and that would break without prior warning. That makes outright removal unacceptable, IMO. The sys module was changed to throw an exception in v0.7 and v0.8 but that resulted in nodejs/node-v0.x-archive#3577 and a subsequent revert in v0.8.1. I'm going to bring this up at the next TC meeting. If we are going to go ahead, then the module should log a warning first for some time, to give people a chance to upgrade their code and dependencies. |
rlidwka
commented
Dec 22, 2014
Burn it with fire:
I have concerns about people screaming "hey, io.js is not compatible with node.js", but other than that, it'd be nice to finally deprecate sys. |
mikeal
commented
Dec 22, 2014
What has changed from the last time we tried to deprecate it? Also, what is the cost of having the link to sys? |
geek
commented
Dec 23, 2014
bnoordhuis
commented
Dec 30, 2014
From today's TC meeting: flat out removing is not the way to go but making @geek If you make the requested changes, I'll land this. Grep lib/ for util.deprecate for examples. |
geek
commented
Jan 7, 2015
@bnoordhuis and @rvagg at what point after a function/module is hard deprecated will it be deleted? |
bnoordhuis
commented
Jan 7, 2015
@geek Probably never. It's not broken and it's not a maintenance burden. Even a deprecation message is somewhat debatable but deprecation messages can be disabled if you really must; at least it shoos people away from using 'sys' in new code. |
vkurchatkin
commented
Jan 7, 2015
@bnoordhuis is this specific to |
bnoordhuis
commented
Jan 7, 2015
@vkurchatkin Just for sys. The consensus was that things that are broken or a maintenance hassle can be phased out given enough time. For the other kind of deprecated (discouraged but not defective), it can stay in perpetuity. |
geek
commented
Jan 8, 2015
@bnoordhuis thanks for the response. Your last comment cleared up what I was getting at... what the policy is for deleting deprecated items. I strongly dislike dead code, particularly because it does add cost to a project. I'll update the PR as outlined above. |
rvagg
commented
Jan 12, 2015
@geek will you be updating this or shal we open it up for others to contribute by submitting a new PR? |
geek
commented
Jan 12, 2015
@rvagg I'll do it now... do you want it in the v1 branch? |
geek
commented
Jan 12, 2015
Closing in favor of #309 |
Namely v8::FunctionCallbackInfo::Holder(), one should use This() method instead. See https://crrev.com/c/5444829 for details.
Namely v8::FunctionCallbackInfo::Holder(), one should use This() method instead. See https://crrev.com/c/5444829 for details.
Namely v8::FunctionCallbackInfo::Holder(), one should use This() method instead. See https://crrev.com/c/5444829 for details.
Namely v8::FunctionCallbackInfo::Holder(), one should use This() method instead. See https://crrev.com/c/5444829 for details.
Namely v8::FunctionCallbackInfo::Holder(), one should use This() method instead. See https://crrev.com/c/5444829 for details.

Related PR on node.js: nodejs/node-v0.x-archive#8880
Larger issue that I want to see addressed: A formal deprecation policy.
My proposal is that any deprecated code get deleted/obsoleted in the next major version. If this is the case, we can delete a lot of other deprecated code that's rotting away :)