Issue #8481 has been updated by shugo (Shugo Maeda).


boris_stitnicky (Boris Stitnicky) wrote:
> Then, if it works lexically, it is not a function of Module, but of ... of ... Kernel? If it modified the module logically, it would be Module's concern. But like this, it is a concern of the interpreter, imao. Something like "private". I don't even know if "private" keyword is method :-)

private is not a keyword.  private at toplevel is the method main.private and private at module level is the method Module#private.  Hence, it's reasonable to provide module-level using as Module#using.

----------------------------------------
Feature #8481: Module#using
https://bugs.ruby-lang.org/issues/8481#change-39680

Author: shugo (Shugo Maeda)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: current: 2.1.0


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?



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