Feature #15357
closed
Proc#parameters returns incomplete type information
Description
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]]
pr.call(:a) # => [:a, 2] # :a is interpret as the first parameter
pr = proc{|a=1,b| [a,b] }
pr.parameters # => [[:opt, :a], [:opt, :b]]
pr.call(:a) # => [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 workaround is used: The proc is passed to define_method and the 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 a property of the Proc object - 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 arguments without default value as type :req as well.
Files
Updated by 
Updated by 
Updated by 
Updated by 
Updated by jeremyevans (Jeremy Evans)