Feature #15357

Updated by larskanis (Lars Kanis) almost 3 years ago

The current implementation of Proc#parameters [differentiate between lambda? true and false]( 
 This is presumably due to the fact, that [procs use tricks]( to apply arguments differently than lambda and methods. 

 Unfortunately `proc{}.parameters` states all `:req` parameters as `:opt`, so that these both types of parameters are not distinguishable. 
 This information loss leads to the situation that two different proc signatures return an equal parameters list, but behave differently: 

 pr = proc{|a,b=2| [a,b] } 
 pr.parameters    # => [[:opt, :a], [:opt, :b]]      # => [:a, 2]    # :a is interpret as the first parameter 

 pr = proc{|a=1,b| [a,b] } 
 pr.parameters    # => [[:opt, :a], [:opt, :b]]      # => [1, :a]    # :a is interpret as the second parameter 

 That means that the current return values of `proc{}.parameters` are not suitable to build wrapper or proxy objects for a proc. 
 In Eventbox a I use the workaround is used: The to pass the proc is passed to `define_method` and [query the [method method parameters are retrieved instead]( 
 That way the list of parameters can be retrieved including `:req` and `:opt` differentiation, so that a wrapper proc can be built. 

 The application of argument assignment tricks is are a property of the Proc object - object, but not a property of single parameters. Therefore it shouldn't be applied to `Proc#parameters` in addition - at least not in a way that discards valuable information. 
 The property of the Proc object is already readable through `Proc#lambda?`, so that there's no need to apply this property to `Proc#parameters` as well. 

 My proposal is to unify `proc{}.parameters` and `lambda{}.parameters`, so that `proc{}.parameters` shows positional returns `:req` arguments without default value as type `:req` as well.