Feature #11919
closedPassing a module directly
Description
Refinement requires a named module:
module MyRefinement
refine ...
...
end
using MyRefinement
but often (but not always), refinements are called by the using
command only in once in a single file, and should not need to be named in such case. Also, the purpose of refinement is to not pollute classes with methods. Necessity to define a module and polluting the name space looks to me to go against this idea.
I would like to do:
using Module.new do
refine ...
...
end
Updated by nobu (Nobuyoshi Nakada) almost 9 years ago
- Description updated (diff)
- Status changed from Open to Feedback
You can write it as
using Module.new {
refine ...
...
}
Or without Module.new
?
using do
refine ...
...
end
Updated by sawa (Tsuyoshi Sawada) almost 9 years ago
Nobuyoshi Nakada wrote:
You can write it as
using Module.new { refine ... ... }
Right. I had forgotten about operator precedence. My example did not make sense.
Or without
Module.new
?using do refine ... ... end
I think this is what I actually wanted to ask for.
Updated by jeremyevans0 (Jeremy Evans) about 3 years ago
I think this feature would be useful, and submitted a pull request to implement it: https://github.com/ruby/ruby/pull/5039
Updated by Eregon (Benoit Daloze) about 3 years ago
I'm rather neutral about this.
On one hand, I think using Module.new {
is clearer that there is a module involved and might avoid some confusion when learning about refinements,
OTOH it seems a fairly harmless shorthand which doesn't do too much magic.
Updated by zverok (Victor Shepelev) about 3 years ago
Discussed here, also: #16241
Copying my comment from there:
I believe that is really a super-good thing. As I've written elsewhere in this tracker, the most useful case for refinements is "in the current module, I want some shortcuts for my code to look cleaner". For example, here and here I experimented with representing some graphics algorithms in a most "readable" way, adding really small methods to the core (Numeric) and RMagick objects. The point is "here, in this module, I crave for some things to exist in some objects".
So, "inplace refinements" is probably the main kind of refinements the developer could care about; while "refinements in a module" could be used, probably, for some "more hygienic" ActiveSupport-alike gems, or some specific blends of Ruby (like
using Geometry
with a ton of specific geometry-related services added to numbers and matrices and whatnot).
Updated by Eregon (Benoit Daloze) about 3 years ago
- Related to Feature #16241: Shorter syntax for anonymous refinements added
Updated by Eregon (Benoit Daloze) about 3 years ago
- Related to Feature #14344: refine at class level added
Updated by Eregon (Benoit Daloze) about 3 years ago
I guess we need to persuade matz then: https://bugs.ruby-lang.org/issues/14344#note-15 (https://bugs.ruby-lang.org/issues/16241#note-5 has some more context)
Updated by jeremyevans0 (Jeremy Evans) about 3 years ago
- Status changed from Feedback to Rejected
Eregon (Benoit Daloze) wrote in #note-8:
I guess we need to persuade matz then: https://bugs.ruby-lang.org/issues/14344#note-15 (https://bugs.ruby-lang.org/issues/16241#note-5 has some more context)
This shows why we need feature triaging. Otherwise developers who are trying to contribute end up working on things that have already been rejected. I'll reject this and close the related pull request.
Updated by sawa (Tsuyoshi Sawada) about 3 years ago
jeremyevans0 thanks for taking up the issue, anyway.
Updated by Dan0042 (Daniel DeLorme) about 3 years ago
@jeremyevans0 (Jeremy Evans) may I ask why you closed this? Matz has not rejected this idea. He only rejected refine X do
(#14344) because refine
should not have such different behavior for class vs module. Although there's also refining X do
(#16241) which may be a better choice since it has Matz' pre-approval.
Updated by jeremyevans0 (Jeremy Evans) about 3 years ago
Dan0042 (Daniel DeLorme) wrote in #note-11:
@jeremyevans0 (Jeremy Evans) may I ask why you closed this? Matz has not rejected this idea. He only rejected
refine X do
(#14344) becauserefine
should not have such different behavior for class vs module.
@matz (Yukihiro Matsumoto) pretty much rejected using do
as well (https://bugs.ruby-lang.org/issues/14344#note-15): the modified syntax using do is also confusing
. So that's why I closed this (this feature is for using do
).
Although there's also
refining X do
(#16241) which may be a better choice since it has Matz' pre-approval.
Not sure where you are seeing pre-approval by @matz (Yukihiro Matsumoto) in #16241. I guess in the description it says that @matz (Yukihiro Matsumoto) indicated refining
seems like a better name than using_refined
, but that doesn't sound like pre-approval to me. #16241 hasn't been rejected yet, though. Personally, I'm not in favor of adding another method for this, so I wouldn't submit a pull request to implement that.
Updated by Dan0042 (Daniel DeLorme) about 3 years ago
jeremyevans0 (Jeremy Evans) wrote in #note-12:
@matz (Yukihiro Matsumoto) pretty much rejected
using do
as well (https://bugs.ruby-lang.org/issues/14344#note-15):the modified syntax using do is also confusing
. So that's why I closed this (this feature is forusing do
).
Ah yes, I don't see how I missed that. Sorry for the noise.
Not sure where you are seeing pre-approval by @matz (Yukihiro Matsumoto) in #16241.
Right, "pre-approval" was the wrong word. I meant it as "preliminary" or tentative endorsement, not as "it's already approved".