Re: Function Prototypes

When you define your subroutine, it does not require parenthesis. Like so:

# Sub definition
sub usage {
  blah...
}

# Calling the sub
usage();
[download]

You only want to use parenthesis if you want to restrict the parameters which may be sent to it. In this instance, that may be the case, but it seems as if you may have done it by accident ;-) If you do choose to use these parenthesis in the sub definition, it's called a prototype.
-Eric

Updated: As currently written, your program doesn't run because you call the subroutine using:

usage();
[download]

When you use a prototype to forbid parameters, you cannot use parenthesis in the subroutine call. You can just use:

usage;
[download]

Now, for someone better with prototypes then myself -- I know this works, because I double checked with the Camel Book before posting. But I don't know _why_ this is the case. On page 226 of Camel 3, it says that with the prototype sub mytime(), one should call it using mytime.

However, going back a few pages to page 222, it talks about how to call subroutines, and what the differences are. It claims that saying foo(); passes a null list to the sub. It then says that using foo; is the same as foo();. Now, that can't be 100% true, if the one won't work with prototypes, but the other does. Does someone know how this is really working?

Comment on Re: Function Prototypes Select or Download Code

Replies are listed 'Best First'.
Re: Re: Function Prototypes by mvaline (Friar) on Jul 03, 2001 at 16:57 UTC
When I removed the parentheses from my subroutine (sorry for using function before) definition, the error ceased to appear. Updated: Given what Zaxo said below, why does the error disappear when I remove the perentheses from the subroutine definition? Since I am in fact no longer "prototyping" the subroutine, does it just relax and assume that I know what I'm doing when I call it before it has been defined? It seems that `perl -w` and `use strict` still ought to catch the fact that I'm calling the it before it's been defined.	[reply] [d/l] [select]
Re: Re: Re: Function Prototypes by chromatic (Archbishop) on Jul 04, 2001 at 01:37 UTC
Page 226 of Camel 3 says "...prototypes are taken into consideration only at compile time...". Dominus or Abigail will probably show up to correct me 30 seconds after I hit submit, but here goes at my explanation anyway. :) Normally (without prototypes), subroutines are defined at compile time. During runtime, you'll get errors about undefined subroutines. There's too much left until runtime to verify things at compile time, what with importing and AUTOLOAD and method dispatch. If you do something like the following -- with our without strict -- you'll get a message that indicates perl finds the construct ambiguous: `foo; sub foo { print "Fooing!\n" }` [download] On the other hand, if you make it clear that foo is a subroutine and not a constant in void context, it's perfectly fine: `foo(); &foo; # or even my $foo = \&foo; $foo->(); sub foo { print "Fooing!\n" }` [download] So it's not really a case of things having to be defined in the correct order because all of this happens at runtime. During compile time, Perl populates the symbol table and resolves what it can. That includes prototypes, and part of the reason seems to be so that you can use them almost as barewords just like built-in functions. That has to happen at compile time. Dunno if that answers your question or muddies the matter. I have only seen a couple of good uses of prototypes, and rarely even think about them.	[reply] [d/l] [select]


Pathologically Eclectic Rubbish Lister
	PerlMonks