Re: Re: Function Prototypes

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.

Comment on Re: Re: Function Prototypes Select or Download Code

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re: Re: Re: Function Prototypes
by chromatic (Archbishop) on Jul 04, 2001 at 01:37 UTC

Dominus

Abigail

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]

foo();
&foo;
# or even
my $foo = \&foo;
$foo->();
sub foo { print "Fooing!\n" }
[download]

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]