3 ms·
> you sure as hell want to check the correctness of every single line of code written using that package Yes, I do. Doing the monkey job of changing every impo
by dmitriid 5y ago
> you sure as hell want to check the correctness of every single line of code written using that package
Yes, I do. Doing the monkey job of changing every import line (which will be done with a global search/replace) is definitely not that.
If you're relying on import statements to tell you which files to check, you're definitely doing something wrong
- deleted 5y ago[deleted]
- paskozdilar 5y agoWhat mechanism, if not the presence of import statements, do you use to locate all the places where a certain package is used in a large project?
- dmitriid 5y ago1. You build your project, and it fails in the places where API changed. IDEs can even pinpoint those locations without building a project 2. You run tests and they fail if the behavior changed Literally nowhere is "oh, do an automatic search/replace of imports" is a tool for fixing your project or figuring out necessary changes. Except in go, apparently.
- deleted 5y ago[deleted]
- paskozdilar 5y agoWillingness to play russian roulette with major versions may work in small organizations. In large-scale, you can't risk subtle behavior change that still compiles. That's the source of many black magic debugging sessions.
- dmitriid 5y agoGrepping and replacing import paths isn't a good tool for finding subtle behavior changes. Especially in big projects.
- paskozdilar 5y agoYeah, but checking each line of code that uses the import is. Especially in big projects.