Project

General

Profile

Actions

Feature #11919

closed

Passing a module directly

Added by sawa (Tsuyoshi Sawada) almost 9 years ago. Updated about 3 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
[ruby-core:72584]

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

Related issues 2 (1 open1 closed)

Related to Ruby master - Feature #16241: Shorter syntax for anonymous refinementsOpenActions
Related to Ruby master - Feature #14344: refine at class levelRejectedActions

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

Actions #6

Updated by Eregon (Benoit Daloze) about 3 years ago

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

Updated by Eregon (Benoit Daloze) about 3 years ago

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

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

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0