From: tom@...
Date: 2017-08-11T04:58:49+00:00
Subject: [ruby-core:82345] [Ruby trunk Feature#13805] Make refinement scope like that of constants

Issue #13805 has been reported by wardrop (Tom Wardrop).

----------------------------------------
Feature #13805: Make refinement scope like that of constants
https://bugs.ruby-lang.org/issues/13805

* Author: wardrop (Tom Wardrop)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
Refinements are currently lexically scoped, which makes their use burdensome when one wants to apply a refinement to an entire project, requiring boiler plate at the top of every project file. I propose that there ought to be a method of applying refinements to an entire namespace (module), similar to how constants are scoped.

For example, here's a trivial example of how one is able to scope a new RuntimeError class inside a module.

~~~ ruby
# a.rb
require 'b'
module MyProject
  class RuntimeError < ::RuntimeError; end
end


# b.rb
module MyProject
  class SomeClass
    def initialize
      raise RuntimeError, "Application error occurred" # Raises MyProject::RuntimeError exception
    end
end
~~~

Could refinements be scoped in a similar way, without the requirement for the `using` clause in every file. For example:

~~~ ruby
# a.rb
require 'b'
module MyProject
  refine! String do
    def exclaim
      self + "!!!"
    end
  end
end


# b.rb
module MyProject
  class SomeClass
    def initialize
      puts "Hello".exclaim # Outputs "Hello!!!"
    end
end
~~~

I believe this would be an intuitive means of making refinements global to a project, which seems to be a highly desired feature, and something that needs to happen to mostly eliminate monkey patching. Of course, using the `refine` name would clash with the current behaviour of refine and break backwards compatibility, so I'd propose introducing `refine!` as an alternative to invoke this proposed new behaviour.

Apologies if this has already been proposed/discussed. I did search for similar proposals, but couldn't find anything. I'm interested to hear what some of the potential pitfalls of this would be.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>