[ruby-core:105677] [Ruby master Feature#18256] Change the canonical name of Thread::Mutex, Thread::Queue, Thread::SizedQueue and Thread::ConditionVariable to just Mutex, Queue, SizedQueue and ConditionVariable
From:
"Eregon (Benoit Daloze)" <noreply@...>
Date:
2021-10-19 10:44:33 UTC
List:
ruby-core #105677
Issue #18256 has been updated by Eregon (Benoit Daloze). nobu (Nobuyoshi Nakada) wrote in #note-3: > The current names have been moved from the top level, to make clarify the roles. I don't understand this reasoning. What else could a Mutex/Queue/SizedQueue/ConditionVariable be for if for threading-related things? There doesn't seem to be any other classes with the same names to disambiguate. Could you or someone else expand on this? There was some discussion about Fiber equivalents but I think we kind of settled on reusing the same classes and they should be Fiber-scheduler aware, because that's just so much more useful and practical for existing code (e.g., the Fiber scheduler is called when a Mutex cannot be acquired immediately for non-blocking fibers). Maybe for Ractor? Ractor can add variants of those if needed, but it also seems clear Actor-like programming should probably avoid most of these abstractions anyway. Also I don't see how the canonical name has any effect on these 60000+ usages, hence it seems needlessly long, and users clearly don't care about what the canonical name is. It's also very clear we will never be able to remove or deprecate them in `Object` given the amount of usages. ---------------------------------------- Feature #18256: Change the canonical name of Thread::Mutex, Thread::Queue, Thread::SizedQueue and Thread::ConditionVariable to just Mutex, Queue, SizedQueue and ConditionVariable https://bugs.ruby-lang.org/issues/18256#change-94177 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- Currently these 4 classes are defined as both constants of `Object` and of `Thread`. On CRuby 3.0.2, their `#inspect` shows they were first defined under `Thread` and then aliased in Object: ``` $ ruby -ve 'p [Mutex, Queue, SizedQueue, ConditionVariable]' ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] [Thread::Mutex, Thread::Queue, Thread::SizedQueue, Thread::ConditionVariable] ``` FWIW this contrasts to TruffleRuby which has: ``` $ ruby -ve 'p [Mutex, Queue, SizedQueue, ConditionVariable]' truffleruby 22.0.0-dev-589c944e, like ruby 2.7.4, GraalVM CE Native [x86_64-linux] [Mutex, Queue, SizedQueue, ConditionVariable] ``` (because these classes are all core now and I thought the Thread:: prefix was the alias since they moved to core) However I believe most usages out there do *not* use the `Thread::` prefix, or in other words almost nobody uses the `Thread::` prefix for those classes. And it seems very clearly confirmed by `gem-codesearch`: ``` $ gem-codesearch 'Thread::Mutex' | wc -l 254 $ gem-codesearch '\bMutex\b' | wc -l 19378 ``` About 75x more common to use `Mutex` than `Thread::Mutex` it seems. ``` $ gem-codesearch 'Thread::Queue' | wc -l 138 $ gem-codesearch '\bQueue\b' | wc -l 38174 ``` About 276x more common to use `Queue` than `Thread::Queue` it seems. ``` $ gem-codesearch 'Thread::ConditionVariable' | wc -l 110 $ gem-codesearch '\bConditionVariable\b' | wc -l 2145 ``` About 19.5x more common to use `ConditionVariable` than `Thread::ConditionVariable` it seems. ``` $ gem-codesearch 'Thread::SizedQueue' | wc -l 27 $ gem-codesearch '\bSizedQueue\b' | wc -l 633 ``` About 23x more common to use `SizedQueue` than `Thread::SizedQueue` it seems. So I propose to update the canonical names of these classes to be without the `Thread::` prefix, to represent the vast majority of usages, and also the fact these classes are core now and not stdlib. In other words, for 3.1.0 I propose: ``` $ ruby -ve 'p [Mutex, Queue, SizedQueue, ConditionVariable]' ruby 3.1.0 ... [Mutex, Queue, SizedQueue, ConditionVariable] ``` -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>