Project

General

Profile

Actions

Feature #8481

closed

Module#using

Added by shugo (Shugo Maeda) almost 11 years ago. Updated almost 11 years ago.

Status:
Closed
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?

Updated by Anonymous almost 11 years ago

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

Updated by matz (Yukihiro Matsumoto) almost 11 years ago

As I already told you, I can accept (or even encourage) this change.
I am interested in how implementers of other Ruby.

Matz.

Updated by shugo (Shugo Maeda) almost 11 years ago

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.

Updated by headius (Charles Nutter) almost 11 years ago

I do not currently have a problem with Module level #using, provided it is still lexical. The same mechanism for file-level #using would work here: if a "using" call is present in the code, we'll treat all calls in that scope as potentially refined (different call logic). Scopes without a #using call will not do refined dispatch.

A few other clarifications I think are important:

  • Since this is lexical, you can't send or send :using from any scope and expect it to work. It might work by accident on some implementations, but this is non-spec. Should it be specified that it explicitly does not work?
  • I assume we still do not have "magic" #send and #instance_method and friends, correct?

Regarding timeline for implementation in JRuby...

Because of the invasive nature of the changes required, we are not comfortable implementing it in the JRuby 1.7.x codebase. Therefore, we will probably not be able to start in earnest on a final implementation until after we branch 1.7. However, I would like to get a prototype implementation based on current 2.0 and upcoming 2.1 refinement features so we can work through issues sooner rather than later. I hope to do that this month...but hope is a complicated thing.

Updated by matz (Yukihiro Matsumoto) almost 11 years ago

  • It's OK that send(:using) do not work
  • we will not provide magic send in the near future (no plan at all)

Matz.

Updated by shugo (Shugo Maeda) almost 11 years ago

headius (Charles Nutter) wrote:

A few other clarifications I think are important:

  • Since this is lexical, you can't send or send :using from any scope and expect it to work. It might work by accident on some implementations, but this is non-spec. Should it be specified that it explicitly does not work?
  • I assume we still do not have "magic" #send and #instance_method and friends, correct?

Agreed. Reflection API should not care refinements in Ruby 2.1.

Because of the invasive nature of the changes required, we are not comfortable implementing it in the JRuby 1.7.x codebase. Therefore, we will probably not be able to start in earnest on a final implementation until after we branch 1.7. However, I would like to get a prototype implementation based on current 2.0 and upcoming 2.1 refinement features so we can work through issues sooner rather than later. I hope to do that this month...but hope is a complicated thing.

I see. Thanks for your effort for refinements.

Actions #7

Updated by shugo (Shugo Maeda) almost 11 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

This issue was solved with changeset r41261.
Shugo, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • eval.c (mod_using): new method Module#using, which activates
    refinements of the specified module only in the current class or
    module definition. [ruby-core:55273] [Feature #8481]

  • test/ruby/test_refinement.rb: related test.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0