[ruby-core:111966] [Ruby master Feature#19366] Rename/alias Refinedment#refined_class => #refined_module

[ruby-core:111966] [Ruby master Feature#19366] Rename/alias Refinedment#refined_class => #refined_module

[zverok (Victor Shepelev) via ruby-core]

Issue #19366 has been reported by zverok (Victor Shepelev).

----------------------------------------
Feature #19366: Rename/alias Refinedment#refined_class => #refined_module
https://bugs.ruby-lang.org/issues/19366

* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:112007] [Ruby master Feature#19366] Rename/alias Refinedment#refined_class => #refined_module

[Eregon (Benoit Daloze) via ruby-core]

Issue #19366 has been updated by 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}.

----------------------------------------
Feature #19366: Rename/alias Refinedment#refined_class => #refined_module
https://bugs.ruby-lang.org/issues/19366#change-101440

* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:112392] [Ruby master Feature#19366] Rename/alias Refinedment#refined_class => #refined_module

[rubyFeedback (robert heiler) via ruby-core]

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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:119962] [Ruby master Feature#19366] Rename/alias Refinedment#refined_class => #refined_module

[shugo (Shugo Maeda) via ruby-core]

Issue #19366 has been updated by shugo (Shugo Maeda).

Status changed from Open to Closed

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


----------------------------------------
Feature #19366: Rename/alias Refinedment#refined_class => #refined_module
https://bugs.ruby-lang.org/issues/19366#change-110693

* Author: zverok (Victor Shepelev)
* Status: Closed
----------------------------------------
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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/