#!perl

use strict;
use warnings;

my $x = shift;

my $sub_name = $x ? 'foo' : 'bar';

eval "*$sub_name = sub { print \"Hello!\n\" };";

foo();
[download]

If the script is passed in a true value, then it will run correctly. If it's passed in a false value, it will not run correctly. But, you want Perl to know what to do before it's been given all the information it might need.

Now, I wouldn't mind seeing an additional optional option added to strict that requires all subroutines, but not methods, to be defined by the time CHECK is complete. But, that's another story.

Here's a sketch of what this should look like. It might even work, as-is.

your_script.pl

use Strict::Subs;
foo(); # The subroutine main::foo might be called but it doesn't exist
+ yet.
[download]

Strict::Subs.pm

package Strict::Subs;
use strict;
use warnings;
use Exporter;
use B::Utils qw( all_roots anon_subs );
use vars qw( %Violations @ISA @EXPORT $VERSION );

BEGIN
{
    $VERSION = '0.01';
    @ISA = 'Exporter';
    @EXPORT = 'strict_subs';

    1;
}

sub import
{
    eval q[
CHECK
{
    # Provide a named way to trigger this
    apply_strict_subs();

    1;
}
];
}

sub strict_subs ()
{
    'strict_subs()';
}

sub apply_strict_subs
{
    local %Violations;

    # All named subroutines.
    {
        my %named_subs = all_roots();
        _strict_sub( $_ ) for values %named_subs;
    }

    # All anonymous subroutines
    _strict_sub( $_->{'root'} ) for anon_subs();

    1;
}

sub _strict_sub
{
    my $root = shift;
    
    walkoptree_filtered( $root,
                         \ &_find_strict_sub_invocation,
                         \ &_apply_strict_subs );

    1;
}

sub _find_strict_sub_invocation
{
    my $op = shift;

    opgrep( { name => 'gv' }, $op )
    and
    do { my $gv = $op->sv;
         ( $gv->NAME eq 'strict_subs'
           and
           $gv->STASH->NAME eq 'Strict' ) }
}

sub _apply_strict_subs
{
    my $op = shift;

    walkoptree_filtered( $_,
                         \ &_find_subroutine_calls,
                         \ &_validate_subroutine_existance )
        for $op->younger_siblings();

    1;
}

sub _find_subrountine_calls
{
    opgrep( { name => 'gv' 
              next => { name => 'entersub ' } } );
}

sub _validate_subroutine_existance
{
    my $op_gv = shift;
    my $gv = $op_gv->sv;
    my $name = $gv->STASH->NAME . '::' . $gv->NAME;

    no strict 'refs';
    *{$name}{'CODE'}
        or warn "The subroutine $name might be called but it doesn't e
+xist yet.\n"
}

package B::Utils;

sub younger_siblings
{
    my $op = shift;

    my @siblings;
    for ( my $sibling = $op->sibling;
          $sibling->oldname ne 'null';
          $op = $sibling )
    {
        push @siblings, $sibling;
    }
    @siblings;
}
[download]

Check out B::Lint. Here's an excerpt from the manual:

undefined-subs
        This option warns whenever an undefined subroutine is invoked.
        This option will only catch explicitly invoked subroutines suc
+h
        as "foo()" and not indirect invocations such as "&$subref()" o
+r
        "$obj->meth()". Note that some programs or modules delay
        definition of subs until runtime by means of the AUTOLOAD
        mechanism.
[download]

ihb

Read argumentation in its context!

#!/usr/bin/perl
use strict;
use warnings;
my $sub = 'foo';
{
    no strict 'refs';
    *{ $sub } = sub { return 'bar' };
}
print foo();
[download]

This is, after all, what happens when you import a module.

A quick browse of CPAN didn't show up any module that would do run-time checks for functions to exist, so it sounds like you have 'an opportunity, rather than a problem'.

That must have been a quick browse :)

Class::Inspector has a bunch of stuff you could use to check for various things.

If your classes don't do any run-time function munging, Test::ClassAPI will let you check for the existance of methods throughout an entire API, and will warn you if it finds extras.

It was indeed a quick browse, combined with an old memory of looking quite hard for this. This time I went through, paying particular attention to the Sub:: hierachy, hence missing them tucked away in Class::. I've written objects before in perl, but I don't think of methods and functions(sub{}s), classes and namespaces as being interchangable, which is kind of implied with your naming scheme.

I do realise that they more-or-less are, but I learned on GWBasic first, so if I can "call" it, I think "It's a sub" :)

Anyway, cool modules and I'm gonna go take the back off them and see what makes them tick. But I'll do it later, I'm too tired now.

___________________
Jeremy
I didn't believe in evil until I dated it.

If you're willing to do that then never call routines directly, instead do them through variables...

#!/usr/bin/perl
use strict;
use warnings;
my $fooz = sub {
  print "Hello, world\n";
};
$foo->();
[download]

The solution is ugly enough that everyone I know is willing to just live with the problem instead.

You could use

    sub foo { ... }

    *foo->(...);
[download]

to receive compile-time warnings, assuming you don't use any other global datatype called foo (and doesn't try to call the same undefined subroutine twice).

Update: boldened "warnings" and added parenthesis.

ihb

Read argumentation in its context!

Interesting idea, but it doesn't seem to work.

tilly@(none):~$ perl -ce 'use strict; *foo->()'
-e syntax OK
tilly@(none):~$ perl -e 'use strict; *foo->()'
Undefined subroutine &main::foo called at -e line 1.
[download]

Tested with Perl 5.8.4.

UPDATE I see, my oversight.

sub foo {
  my $thing = shift;
  $thing->bar();
}
[download]

HOWEVER, variables can also be made on the fly, so it seems like a stupid argument, because 'use strict' can enforce that variables be declared somewhere.

Strictures enforces this because it is much less likely you will want to use a variable that has been defined on the fly than a subroutine that has. In fact, defining subroutines on the fly is the basis of several styles of programming. I haven't heard of a style that depends on defining variables on the fly. And, frankly, if you did, you'd use a hash. :-)

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

~/info> perl -Mstrict -c -e 'foo()'
-e syntax OK

~/info> perl -Mstrict -c -e 'foo'
Bareword "foo" not allowed while "strict subs" in use at -e line 1.
-e had compilation errors.
[download]

That doesn't always work due to indirect object syntax. Here's an example of when lack of parenthesis doesn't help, and the call instead gets interpreted as a method call rather than a function call.

    $ perl -Mstrict -cwe 'my $bar; foo $bar;'
    -e syntax OK
[download]

ihb

Read argumentation in its context!