Issue #13805 has been updated by shevegen (Robert A. Heiler).


I do not think that issue #4085 necessarily has to be the "one and only one true refinement", in 
particular if we keep in mind that towards ruby 3.x, even syntax changes could happen if they
may make sense (and matz would approve).

On a general side note, I wonder whether I am the only one who dislikes the syntax in regards to
refinements; that includes both the current form but also the "refine!" variant. For some reason,
the syntax does not seem to fit into ruby code I write but perhaps that is just me. It's weird
because I am in full agreement that refinements are good to be had, but the syntax is ... strange.

Especially the "using" clause, so in one way or another, although I dislike the "refine!" variant
used by Tom above, I actually understand his syntax proposal a bit. Then again perhaps I
misunderstood it.

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

Well, in the worst case, you could target ruby 3.x - matz said at a conference that the major
reason why he will not eliminate (too much?) existing functionality is to stay backwards
compatible in the 2.x branch, whereas the 3.x could possibly include such changes. So I think
you could actually propose any alternative syntax if it were to target 3.x (which is destined
loosely towards the year ~2020, give or take).

----------------------------------------
Feature #13805: Make refinement scoping to be like that of constants
https://bugs.ruby-lang.org/issues/13805#change-66148

* 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>