I always use parens when calling user-defined subroutines and methods (except when playing golf) because:

• The consistency of always using parens when calling user-defined subroutines/methods makes the code easier to read (for me).
• Code tends to be more robust if it is reorganized in the future. For example, if you later switch from use (compile-time) to require (run-time) (to speed initial module load or when porting to a new platform, say) your code may break in surprising ways. Even if you can "easily" fix the code to use parens (so that it will parse correctly with require), doing so risks breaking what might be thousands of lines of working production code ... so avoid that future risk by always using parens in the first place.

Very well put, ++eyepopslikeamosquito.

To me, the consistent use of parentheses when calling user-defined subroutines and all methods makes the code more readable. It looks nicer.

G'day quixadhal,

When in doubt, you can check how Perl will parse your code fragment from the command line, rather than having to run a (test) script, with this:

perl -MO=Deparse,-p -e '... code fragment here ...'
[download]

See B::Deparse for more information about this.

"In most cases, I find I can happily write code which calls functions without needing to use those pesky parenthesis, other than to clarify which arguments are being passed, and which are part of another expression." [my emphasis]

Clarification is exactly what's needed here. Perl doesn't know if you meant

$self->selector->remove($self)->listener;
[download]

or

$self->selector->remove($self->listener);
[download]

Notice in the following what's valid and invalid syntax:

$ perl -MO=Deparse,-p -e '$self->selector->remove $self->listener;'
Scalar found where operator expected at -e line 1, near "->remove $sel
+f"
    (Missing operator before $self?)
syntax error at -e line 1, near "->remove $self"
-e had compilation errors.
[download]

$ perl -MO=Deparse,-p -e '$self->selector->remove($self)->listener;'
$self->selector->remove($self)->listener;
-e syntax OK
[download]

$ perl -MO=Deparse,-p -e '$self->selector->remove($self->listener);'
$self->selector->remove($self->listener);
-e syntax OK
[download]

For more information about calling methods, see perlobj. In particular, these three sections of that documentation:

• Method Invocation
• Method Call Variations
• Invoking Class Methods [Especially noting the strongly discouraged Indirect Object Syntax]

Method calls require parentheses unless they take no arguments.

If you want one single rule about when to use parentheses, this is probably the closest thing you're going to get:

If Perl is able to figure out what sub is getting called at compile time, you don't usually need parentheses because Perl can use prototypes to figure out how to parse the sub call and argument list. Otherwise, Perl can't use prototypes, so you have to fall back to Perl's default parsing for the sub call and argument list.

In the case of $self->selector->remove, Perl can't figure out what remove sub is going to get called at compile time, because it has no idea what kind of object $self->selector will return. This goes for all method calls. Perl always has to defer to run time to decide which sub will get called. Thus Perl always has to defer to its default parsing, which is: if the method name is followed by an opening parenthesis, a list of arguments begins; if it's followed by anything else (including EOF), then the list of arguments is empty.

For function calls (i.e. sub calls which are not method calls), the default parsing behaviour (i.e. when Perl encounters a sub call where it can't figure out which sub is being called at compile-time) is: if the function name is followed by an opening parenthesis, a list of arguments begins; if it's followed by anything else, then the behaviour depends on whether strict is in effect. If strict is in effect, the parser throws an exception; otherwise the parser treats the function name as a bareword string.

These "default" parsing rules are for when Perl cannot determine which sub is getting called at compile time. Often Perl can determine this for function calls (but never for method calls) - for example if the sub was declared earlier in the same file, or if it was imported earlier in the same file. In cases where it can determine which function is getting called, then the rules aren't as simple. ;-) Perl has to take into account the prototype of the sub (if any), plus any custom parsing rules that have been established for the sub (i.e. the Perl keyword API).