package Foo;

sub new {
    print "Right one!\n";
}

1;
--------
#!/usr/local/bin/perl

use Foo;

# Insert 1000 lines of code here

sub new {
    print "Wrong one!\n";
}

# Insert 1000 lines of code here

my $bar = new FOO;
# Compare that with my $bar = FOO->new;
[download]

The only reasons I can ever see to use indirect notation are the following:

1. You're a C++ programmer that doesn't want to really learn Perl
2. You want to do that "cool thing" in Llama3 with no parentheses on method calls.

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

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Hmmm...

package Gotcha;

sub bar {
  print "Didn't think you would go here, huh?\n";
}

package Foo;

sub bar {
  print "This is what you probably thought would happen?\n";
}

package main;

sub Foo {
  "Gotcha";
}

Foo->bar();
Foo::->bar();
[download]

Unless you always slip that :: in, the main reason that the direct notation is safer than the indirect is that you are more likely to give different classes the same method names than you are to name a function and a class the same thing.

That said, my aesthetic preference is for the direct notation.

By using indirect notation, you're removing the capability for the interpreter to spellcheck you if you have defined a new function in the current package.

I find this less than compelling, perhaps because I always use parenthesis on method or function calls.   my $bar = new FOO(); isn't going to be tripped up by having written a new routine in the current package. Consider

package FOO;

sub new {
    print "right!\n";
}

package BAR;

sub new {
    print "wrong!\n";
}

my $f = new FOO();   # prints "right!"
[download]

Update: hold on, my $f = new FOO;    # also prints "right!" Where's the problem?

Interesting! Anyone want to explain why this works??

However, the syntax looks horrible. You have parentheses, indicating a function or method name, on a token indicating a package name. This looks to be a very poor design decision, in my opinion.

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

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.