Project

General

Profile

Actions

Feature #9451

closed

Refinements and unary & (to_proc)

Added by rbjl (Jan Lelis) almost 11 years ago. Updated about 8 years ago.

Status:
Closed
Target version:
-
[ruby-core:60109]

Description

Not sure if this is a bug or feature request:

require 'minitest/autorun'
require 'set'

module ClassToProc
  refine Class do
    def to_proc
      lambda{ |*args| self.new(*args) }
    end
  end
end

using ClassToProc

describe 'Class#to_proc' do
  it 'works when called directly' do
    Set.to_proc[[1,2]].must_equal Set[1,2]
  end

  it 'fails when called via ampersand' do
    [[1,2]].map(&Set).must_equal [Set[1,2]]
  end
end

The second example errors with NoMethodError: super: no superclass method `to_proc' for Set:Class

Would be great to have it, though.


Related issues 2 (0 open2 closed)

Has duplicate Ruby master - Feature #12638: Symbol#to_proc probable bug (seems not to support refinements)ClosedActions
Has duplicate Ruby master - Feature #12079: Loosening the condition for refinementRejectedmatz (Yukihiro Matsumoto)Actions

Updated by matz (Yukihiro Matsumoto) almost 11 years ago

  • Assignee set to shugo (Shugo Maeda)

As #=== from case statement and #each from for statement, I think refinement should be effective to methods that called implicitly. Let us discuss about the issue.

Matz.

Updated by shugo (Shugo Maeda) almost 11 years ago

  • Tracker changed from Bug to Feature

Yukihiro Matsumoto wrote:

As #=== from case statement and #each from for statement, I think refinement should be effective to methods that called implicitly. Let us discuss about the issue.

What do you think of other implicit conversions such as to_a called by the splat operator.

Updated by shugo (Shugo Maeda) almost 11 years ago

  • Category set to core
  • Status changed from Open to Assigned
  • Assignee changed from shugo (Shugo Maeda) to matz (Yukihiro Matsumoto)
  • Target version set to 2.2.0

I'd like to clarify the design policy rather than adding features ad hoc.

All implicit method calls in syntactic constructs should be affected by refinements, right?
Do other implementers, especially JRuby people, accept this policy?

Updated by nobu (Nobuyoshi Nakada) over 10 years ago

  • Description updated (diff)

IMHO, splat should be affected by refinements, because there is no intermediate method calls.

Updated by justcolin (Colin Fulton) almost 9 years ago

Is there any update on this feature? In Ruby 2.2.3 I still run into a problem where the unary & can not be used when the method was added with a refinement, such as the following:

module Example
  refine String do
    def pugs
      "Pugs!"
    end
  end
end

using Example

('a'..'z').map(&:pugs)

I can understand why they currently do not work, but it leads to uglier code.

Cheers!

Updated by justcolin (Colin Fulton) almost 9 years ago

Sorry, just saw that issue 9786 is equivalent to this one and was marked as rejected. Thanks!

Actions #7

Updated by nobu (Nobuyoshi Nakada) over 8 years ago

  • Has duplicate Feature #12638: Symbol#to_proc probable bug (seems not to support refinements) added

Updated by matz (Yukihiro Matsumoto) about 8 years ago

I now think it's OK to accept this proposal. But I don't know how difficult to implement the issue.

Matz.

Actions #9

Updated by shugo (Shugo Maeda) about 8 years ago

  • Has duplicate Feature #12079: Loosening the condition for refinement added
Actions #10

Updated by nobu (Nobuyoshi Nakada) about 8 years ago

  • Status changed from Assigned to Closed

Applied in changeset r56426.


vm_args.c: allow refinements in Symbol proc

  • vm_args.c (refine_sym_proc_call): search and call method with
    refinements.
  • vm_args.c (vm_caller_setup_arg_block): enable refinements when
    enabled in the caller. [Feature #9451]
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0