Feature #19366: Rename/alias Refinedment#refined_class => #refined_module

• Status: Closed
• Assignee: -
• Target version: -

[zverok (Victor Shepelev)]

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:

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, 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.

[Eregon (Benoit Daloze)]

Agreed, I think it's fine to have both refined_class and refined_module, much like we have {module,class}_{eval,exec}.

[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

[shugo (Shugo Maeda)]

• Status changed from Open to Closed

After discussions in [Feature #19714], Refinement#target was added, so I close this issue.

[hsbt (Hiroshi SHIBATA)]

• Related to Feature #19714: Add Refinement#refined_module added