Ticket #1033 (new RFC)

Opened 12 years ago

Last modified 10 years ago

no args checking for a sub without params

Reported by: coke Owned by:
Priority: normal Milestone:
Component: imcc Version: trunk
Severity: medium Keywords: gci
Cc: whiteknight Language:
Patch status: Platform:

Description

Originally reported in  RT.

If no .params are given, no args checking is done on sub invocation. From the original:

On Sat Jul 15 23:29:10 2006, mdiep wrote:
> I expect this to die with a "too many args" error, but it doesn't -- 
> it prints "ok":
> 
> .sub main :main
> test("foo", "bar")
> end
> .end
> 
> .sub test
> print "ok\n"
> .return()
> .end
> 
> --
> Matt Diephouse
> 

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

Change History

in reply to: ↑ description   Changed 12 years ago by wagle

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.

  Changed 12 years ago by wagle

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?

  Changed 12 years ago by wagle

PPS. That is, the http doc's suggest P, and make no mention of PMC as an option to :multi.

follow-up: ↓ 6   Changed 12 years ago by wagle

PPPS. I don't stop thinking:

my getter is marked :multi(), yet accepts arity-2 calls. I can't see how that's correct.

  Changed 12 years ago by dukeleto

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.

in reply to: ↑ 4   Changed 12 years ago by pmichaud

my getter is marked :multi(), yet accepts arity-2 calls. I can't see how that's correct.

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

  Changed 12 years ago by bacek

  • component changed from none to imcc

follow-up: ↓ 9   Changed 11 years ago by cotto

  • keywords gci added

gci task created for this ticket

in reply to: ↑ 8   Changed 10 years ago by jkeenan

  • cc whiteknight added

Replying to cotto:

gci task created for this ticket

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

Note: See TracTickets for help on using tickets.