Issue #19366 has been updated by rubyFeedback (robert heiler). This is in part a problem of having the "duality" of classes and modules. matz explained that in the past, in part due to not liking the complexity and potential confusion of C++ multi-inheritance, when explaining why modules were added. For me, I don't have an issue, but there was one syntax situation I found awkward: I need to sometimes know whether it is a class or a module that I am modifying. So I may have code: module Foo module Bar class Baz versus: class Foo::Bar::Baz It's not a huge issue, but ruby would yield an error if I specify a class or module incorrectly (which can happen if you spread code out into different .rb files, so I understand why there is an error message shown, to avoid accidents). But I then also wondered why I have to care whether it is a module or class, if my **primary** goal is to modify something, such as by adding a method. If I want to add a method: def foobar; end then I really should never be required to have to know whether I am modifying a class or a module. Again, it's not any huge issue, but I wondered about it. And that's what I mean with the "duality" situation here. I guess zverok in part refers to this too, because that "duality" leads to him questioning what the proper name is: refine_class, or refine_module, or any other name. So I can somewhat understand it.
the method should be renamed or aliased.
I think aliasing may be better so people can use what they prefer. benoit wrote:
I think it's fine to have both refined_class and refined_module, much like we have {module,class}_{eval,exec}.
I do not disagree, but I would also like to point out that it can confuse newbies, e. g. when they wonder whether they should use class_eval or instance_eval. Some concepts are not trivial to remember offhand. I still have not really used refinements myself, oddly enough. I agree with the concept, but the syntax feels kind of weird ... I am so used to syntax such as: class Foo < Bar or even just include Foo extend Bar ---------------------------------------- Feature #19366: Rename/alias Refinedment#refined_class => #refined_module https://bugs.ruby-lang.org/issues/19366#change-101834 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- In #12737, `Refinement#refined_class` is introduced. As "module" is more generic concept than "class", the name misleadingly implies that either this method doesn't returns refined _modules_, or modules can't be refined. This is obviously not true and trivially disproved: ```ruby module Refs refine Enumerable do def foo = puts 'foo' end end Refs.refinements[0].refined_class #=> Enumerable. Which is, well, not a class. # The refinement is usable, so it is not a mute concept: using Refs [1, 2, 3].foo # prints "foo" successfully ``` I believe we refer to "modules" when some feature applies to modules and classes. Unless there is some deeper consideration for the current naming (I don't see justification in #12737, but I might miss something), the method should be renamed or aliased. PS: Sorry for a huge amount of "nitpicky" issues after the version release. Typically, those concerns emerge while I am working on the [changelog](https://rubyreferences.github.io/rubychanges/), and I am usually trying to start the work at least a month before the release. Unfortunately, due to you-know-what, I was unable to do it in time this year. After the 3.2 changelog, I plan to switch to the "master changelog" approach (following the development with the "current unreleased changes" document) this year. Unless I'll be unable to due to reasons not in my control. -- https://bugs.ruby-lang.org/