Feature #11919: Passing a module directly

• Status: Rejected
• Priority: Normal
• Assignee: -
• Target version: -

[sawa (Tsuyoshi Sawada)]

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

[nobu (Nobuyoshi Nakada)]

• 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

[sawa (Tsuyoshi Sawada)]

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.

[jeremyevans0 (Jeremy Evans)]

I think this feature would be useful, and submitted a pull request to implement it: https://github.com/ruby/ruby/pull/5039

[Eregon (Benoit Daloze)]

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.

[zverok (Victor Shepelev)]

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

[Eregon (Benoit Daloze)]

• Related to Feature #16241: Shorter syntax for anonymous refinements added

[Eregon (Benoit Daloze)]

• Related to Feature #14344: refine at class level added

[Eregon (Benoit Daloze)]

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)

[jeremyevans0 (Jeremy Evans)]

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

[sawa (Tsuyoshi Sawada)]

jeremyevans0 thanks for taking up the issue, anyway.

[Dan0042 (Daniel DeLorme)]

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

[jeremyevans0 (Jeremy Evans)]

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) because refine 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.

[Dan0042 (Daniel DeLorme)]

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 for using 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".