Ruby 3 has just released - hooray! But naturally, some of my code hit problems with Ruby 3's breaking changes.
Almost all of these were related to Ruby 3's changes to how keyword arguments are handled, but I also had an intriguing issue reported on my Sord type generation project.
Ruby used to include a SortedSet
class, but it's been removed from Ruby 3 for "dependency and performance reasons". Suppose we try to use it...
irb(main)> SortedSet
RuntimeError (The `SortedSet` class has been extracted from the `set` library.You must use the `sorted_set` gem or other alternatives.)
Woah, what's that error message!? That's not usually what we see when we try to use a constant which doesn't exist. You'd expect to get something like:
NameError (uninitialized constant SortedSet)
SortedSet
gives us a much more useful error message.
How does Ruby do this? Let's take a look!
My first guess was that Ruby 3 replaced the SortedSet
class with a SortedSet
method which throws an exception. It's not unusual for the Ruby Kernel
to have methods which look like classes, so I thought this was a pretty good guess. But nope, there isn't any SortedSet
method:
irb(main)> method(:SortedSet)
NameError (undefined method `SortedSet' for class `#<Class:#<Object:0x000056382e0a84c8>>')
To dig a bit deeper, I took a look at the Ruby interpreter source code. The lib/set.rb
file revealed the answer:
autoload :SortedSet, "#{__dir__}/set/sorted_set"
SortedSet
is now defined with autoload
. Referencing SortedSet
will require the given file to try and resolve that constant, acting as a kind of lazy-loading within a Ruby program.
Sure enough, the useful exception we were seeing is thrown by the sorted_set
file which autoload
points to:
begin
require 'sorted_set'
rescue ::LoadError
raise "The `SortedSet` class has been extracted from the `set` library." \
"You must use the `sorted_set` gem or other alternatives."
end
This is a really clever way of providing useful error messages when functionality is broken out or removed, which I personally haven't seen before!
There is one quirk with it though, and it's the cause of the bug which made me look into this in the first place.
SortedSet
is still a constant, so Object.constants
contains it. But accessing this constant isn't always safe if you don't have the sorted_set
gem. This means that iterating over all available constants can throw an exception!
Object.constants.each do |c|
p Object.const_get(c)
end
# => KeyError
# => Thread::Queue
# => IndexError
# ...etc, until boom!
# => RuntimeError (The `SortedSet` class has been extracted from the `set` library.You must use the `sorted_set` gem or other alternatives.)
I can see this being a problem in some heavily-metaprogrammed environments, just like it was for Sord.
For what's basically just a custom error message, I found this approach to the removal of SortedSet
interesting to think about.
Is breaking a common assumption like "reading a constant which exists won't throw an exception" worthwhile when it might help out the developer?
Or, on the other hand, is consistency key to maximise the effectiveness of Ruby's metaprogramming? Do edge cases like this introduce complexity which makes the internals of Ruby more difficult to understand?
Personally I think this minor touch is a great design decision in Ruby 3, even if it did introduce a bug that had to be solved. If you have any other thoughts, I'd be interested to hear them!
Top comments (0)