61–70 of 148 posts
Much better to annotate those functions with @deprecated and allow running in "deprecated allow mode" and a "deprecated fail mode"... Never use profanity in your code, nor in your comments. Lets keep things professional.
Much better to annotate those functions with @deprecated and allow running in "deprecated allow mode" and a "deprecated fail mode"... Never use profanity in your code, nor in your comments. Lets keep things professional.
If you do the above, your prod servers will always run in "deprecated allow" mode because developers continue to use (and add new) deprecated functionality. That's what the article is attempting to tackle. Why not use profanity in code? We're all adults.
Earlier quoted context omitted.
If you do the above, your prod servers will always run in "deprecated allow" mode because developers continue to use (and add new) deprecated functionality. That's what the article is attempting to tackle. Why not use profanity in code? We're all adults.
Prod should always be running in allow mode anyway for the same reason that prod builds compile out debug asserts and static type checks. Once the code passes review and makes it into prod you've already lost and spitting out warnings on every function invocation will just piss off your ops team.
I'm more curious about how things like shitlists are implemented in different languages. Most of my experience is C#, where calling deprecated code triggers a warning. Considering that C# warnings will fail in CI, how would someone do a C# shitlist? Would it require some kind of #pragma, that would stick out like a sore thumb in a code review
The ability to grandfather in existing violations, though, is something most build tools are likely to have trouble with.
Maybe another way to do it is to have warnings fail CI, but grep out the known offenders from stderr.
None of that sounds elegant to me, but it _is_ a shitlist.
It's better to use a Shiterator, which can yield pieces of shit on demand, lazily enumerate them just in time, and generate infinite streams of shit, instead of allocating all your shit up front, and having your shit together in one place.
If you don't want people to use deprecated code, it's essential to document what the replacement should be. In JavaWorld, this can be done through Javadoc. Just tagging a method or class with @Deprecated and leaving it there is the sort of thing that makes me want to hurt people.
Earlier quoted context omitted.
Does go-lang not have "official" repos, including clones of popular repos, to avoid deps on personal repos? Or is this an "unofficial but popular" library?
Go imports are done by direct github URL mostly.
Earlier quoted context omitted.
I don't understand what this has to do with the article or the previous comment at all.
The article is about deprecating and taking functionality out of use. My point is that deprecation is by its very nature going to hurt something that isn’t prepared for its demise. There is no good way to do it. There are only less bad ways to do it.
> My point is that deprecation is by its very nature going
> to hurt something that isn’t prepared for its demise.
You're describing the end of Life of Adobe Flash that hits at the end of 2020.
Deprecation is different from EOL (Flash has been deprecated for some time now), and deprecating/EOLing a creation tool/product line has little similarity with tooling to deprecate internal APIs gracefully.
Although I do think that you and TFA agree on how difficult it is to deprecate functionality that folks rely on, it seems like you're talking about two wildly different facets of that statement.
Earlier quoted context omitted.
... windows ? MacOS ? Literally every Adobe software ? Literally every large audio / video / 3d création software ? Every large game engine ? I don't know, I notice pretty much the opposite in the field of software I know - smaller software come and go, but the large ones were there 20 years ago and will likely still be there in twenty years
So you'd write a new application using win32? There is a lot of inertia driving maintenance on some of these large products but there is also a ton of deprecation taking place internally relative to them.
I will probably remember Sirupsen forever for his move of breaking Golang projects by renaming his github username. This led to go modules freaking out because different project used different name casing for the dependency. He has a popular logging library and go modules are angry when you rename github usernames..