Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

extending RubyProc to easily trigger arity check? #3499

Closed
kares opened this issue Nov 26, 2015 · 4 comments
Closed

extending RubyProc to easily trigger arity check? #3499

kares opened this issue Nov 26, 2015 · 4 comments
Milestone
Invalid or Duplicate

Comments

@kares
Copy link
Member

kares commented Nov 26, 2015

currently a RubyProc instance only seems to validate args if its a lambda (which is fine of course).

however I stumbled upon an "edge" case from MRI 2.3.0-preview1 where a non-lambda does validation.
Hash#to_proc seems to be an exceptional case, behaves (does not seem like a bug in MRI) :

    h = { 1 => 10, false => true, '2' => :'20' }
    assert_equal false, h.to_proc.lambda?
    proc = h.to_proc
    assert_equal 10, proc.call(1)
    assert_equal true, proc.call(false)
    assert_equal nil, proc.call(2)

    assert_raises(ArgumentError) { proc.call }
    assert_raises(ArgumentError) { proc.call 1, 2 }

please review, should it get refactored in any way - does it seems like a hack to you guys to sub-class :
55fdd00 // cc @enebo @subbuss

p.s. also tried :symbol.to_proc.call 1, 2, 3 but that seems to accept any number of arguments ... like a plain-old Ruby proc.
@kares kares changed the title extending RubyProc to easily trigger arity check extending RubyProc to easily trigger arity check? Nov 26, 2015
@enebo
Copy link
Member

enebo commented Nov 26, 2015

@kares I think extending RubyProc is fine but there seems to be no block semantics in the underlying method (e.g. arity must be 1 and there are no captures). So you might want to just implement call directly in StrictProc (which I would rename to HashProc).

@kares
Copy link
Member Author

kares commented Nov 29, 2015

right - seemed over complicated so I simplified with a RubyProc sub-class: kares@b24bad1

... but than I realized that won't work since the block can not stay at NULL_BLOCK due isGiven
and sub-classing a Block only mean unfinalizing the runtime Block class, is that right to do ?

@enebo
Copy link
Member

enebo commented Nov 30, 2015

@kares ah ick! I guess we do need a specialized version of block after all :|

@kares
Copy link
Member Author

kares commented Dec 2, 2015

closing (for now). on ruby-2.3 a custom Block sub-class has been invented (which required class Block to be no longer final) - that seems to cover all the cases without sub-classing a BlockBody : b2cac04

@kares kares closed this as completed Dec 2, 2015
@kares kares added this to the Invalid or Duplicate milestone Dec 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Invalid or Duplicate
Development

No branches or pull requests
2 participants
@enebo @kares