As I mentioned at the start of my Optimizing Ruby’s JSON series of posts, performance isn’t why I candidated to be the new gem’s maintainer.
The actual reason is that the gem has many APIs that I think aren’t very good, and some that are outright dangerous.
As a gem user, it’s easy to be annoyed at deprecations and breaking changes. It’s noisy and creates extra work, so I entirely understand that people may suffer from deprecation fatigue. But while it occasionally happens to run into mostly cosmetic deprecations that aren’t really worth the churn they cause (and that annoys me a lot too), most of the time there’s a good reason for them, it just is very rarely conveyed to the users, and even more rarely discussed, so let’s do that for once.
So I’d like to go over some of the API changes and deprecations I already implemented or will likely implement soon, given it’s a good occasion to explain why the change is valuable, and to talk about API design more broadly.
Dealing With Deprecations in Ruby
But before I delve into deprecated API, I’d like to mention how to effectively deal with deprecations in modern Ruby.
Since Ruby 2.7, warning messages emitted with Kernel#warn are categorized, and one of the available categories is :deprecated . By default, deprecation warnings are silenced; to display them, you must enable the :deprecated category like so:
Warning [ :deprecated ] = true
It is very highly recommended to do so in your test suite, so much so that Rails and Minitest will do it by default.
However, if you are using RSpec, you’ll have to do it yourself in your spec_helper.rb file, because we’ve tried to get RSpec to do it too for over four years now, but without success. But I’m still hopeful it will eventually happen.
... continue reading