Project

General

Profile

Feature #8481

Module#using

Added by shugo (Shugo Maeda) about 7 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Target version:
[ruby-core:55273]

Description

As I said at RubyKaigi2013, refinements in Ruby 2.0 have a problem that it's impossible to use incompatible refinements in the same file.
And at RubyKaigi, I've proposed the new option using: of instance_eval, by which you can activate refinements in the specified module only in the given block.
See my presentation slides for details: http://shugo.net/tmp/refining_refinements.pdf

However, Matz doesn't like that idea for the following two reasons:

  1. It's difficult for users to expect what refinements are activated in a block.
  2. It's difficult for Ruby implementors to implement it efficiently.

So, I propose Module#using instead of the using: option of instance_eval.
Module#using had once been introduced into trunk, but it was removed from Ruby 2.0.
I'd like to make it simpler, as follows.

  1. Module#using activates refinements in a given module only in the current class or module definition.
  2. So Module#using is private and the receiver of Module#using should be self.
  3. The refinements never be activated in class or module definitions reopened later.
  4. The refinements never be inherited to subclasses.

That is, Module#using works lexically.

EXAMPLE 1

class Foo
using Ref1
# Refinements in Ref1 are activated only in the current definition of Foo.
end
class Bar
using Ref2
# Refinements in Ref2 are activated only in the current definition of Bar.
end

EXAMPLE 2

class Foo
using Ref1
# Refinements in Ref1 are activated only in the current definition of Foo.
end
class Foo
# Refinements in Ref1 are not activated here.
end

EXAMPLE 3

class Foo
using Ref1
# Refinements in Ref1 are activated only in the current definition of Foo.
end
class Bar < Foo
# Refinements in Ref1 are not activated here.
end

Any thoughts?

Also available in: Atom PDF