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.
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
no args checking for a sub without params #600
Comments
I was trying to distinguish between a getter (0 args) and a setter (1 arg), and the getter was grabbing things with 1 arg, which I think is a total error. I understand that its a (sloppy) unix idiom to often pretend that :main receives 1,2, or 3 args, so I could see :main setting up a complex :multi (and/or implied .param's) for that. Everything else is an error. Squash it now, it ain't going to get better with time. Add a catch-all dummy .param option if you must. By the way, my zero-arity getter was marked :multi(), making it twice the error (?) for it to accept arity-1 calls, ESPECIALLY since there was a arity-1 acceptor (ie, the setter) sitting there, ready. |
PS. I initially annotated the setter with :multi(P), which didn't accept anything I sent at it. :multi(PMC) fixed that (as did :multi(_)), so my getter and setter work for 0 and 1 args, but not 2, etc. Could someone add some examples (besides :main) of why you would want 0-arity sub's to be grab-all's? |
PPS. That is, the http doc's suggest P, and make no mention of PMC as an option to :multi. |
PPPS. I don't stop thinking: my getter is marked :multi(), yet accepts arity-2 calls. I can't see how that's correct. |
It seems that throwing an exception when no function of the correct arity is found should be the correct behavior. This probably incurs a deprecation policy. |
The :multi() pragma is used only to constrain the types and minimum number of arguments, it does not provide an arity-based constraint. In particular, :multi(Foo?) simply says that the first argument must be of type 'Foo', it doesn't limit the sub to calls with only one argument. :multi(_) says that a sub requires at least one argument (but may have more), and that argument may be of any type. Thus ":multi()" simply says that a given sub is a MultiSub and has to have at least zero arguments to be invoked (but is allowed to have more). Pm |
gci task created for this ticket |
Replying to cotto:
This wasn't taken up by any of the GCI students. whiteknight, given the work you've done on IMCC, do you have any opinion on this? Thank you very much. kid51 |
Although it's been more than a year since I was poking around bytecode/IMCC, I believe this is caused by the fact that IMCC doesn't emit any of the get_param, etc. ops when there are no .param directives. So argument handling is simply never called. (And hence, never has an opportunity to check arity.) |
Originally reported in [http://rt.perl.org/rt3/Ticket/Display.html?id=39844 RT].
If no .params are given, no args checking is done on sub invocation. From the original:
2 sample patches to achieve this (both of which are declared to fail) are attached to the original ticket. Neither apply cleanly to trunk.
There is a question, however, as to whether or not the existing behavior is desirable - should we always check args? should we always check except for :main? (should we check for :main too and suggest that the programmer use .param args :slurpy to avoid any issues?)
There's a test already committed in t/op/calling.t
Originally http://trac.parrot.org/parrot/ticket/1033
The text was updated successfully, but these errors were encountered: