Re^3: explanation of constant syntax? (clear)

Yep, constants aren't very clear in Perl... unless you write them like FOO(). It clears up what is really going on to the user.

It also clears up what is going on to Perl. Barewords are quite ambiguous in Perl. Is it a function call, a string, a reserved word, a file handle, a package name, ... ? Sometimes Perl is forced to guess and sometimes guesses wrong (just like in the original node). So I almost always add the trailing parens to make things clear to man and beast.

One exception is that I sometimes call subroutines that take arguments without the parens to get compile-time notice when I mispel the routine name. But I only do that for statements (never in the middle of an expression), because there are even more ambiguities to trip on.

- tye

Comment on Re^3: explanation of constant syntax? (clear)

Replies are listed 'Best First'.
Re^4: explanation of constant syntax? (clearer?) by Aristotle (Chancellor) on Mar 20, 2004 at 19:00 UTC
I'm not sure that's necessarily helpful. The value of constant subs gets inlined at compile time, so while they share the syntax of function calls they do not share their semantics. There is no function call, even though it looks like one to the reader. Makeshifts last the longest.	[reply]
Re^5: explanation of constant syntax? (clearer!) by tye (Sage) on Mar 21, 2004 at 04:45 UTC
Yes, FOO() is clearer than FOO or (FOO). The latter two could be strings or file handles or perhaps other things. Yes, you can't tell whether FOO() is a constant function and so whether FOO() gets called at compile time or at run time. But neither FOO nor (FOO) make that any clearer, either. Earlier today you wrote `my $tmp = io;` [download] and io() isn't a constant, so you don't appear to reserve bareword usage for constants. So, how can the more ambiguous syntax be anything but less clear? You know that the function doesn't get called at run time for constants. But that is an implementation detail and an optimization and so isn't particularly important. It doesn't change the function of the program and not knowing about it isn't going to trip you up when you try to understand what the code is doing. I've certainly never been in a situation where I've slapped my forehead and said "Of course! That's why it isn't behaving right. I didn't (notice\|put in) (the lack of\|) the empty prototype!". - tye	[reply] [d/l]
Re^6: explanation of constant syntax? (not so sure) by Aristotle (Chancellor) on Mar 25, 2004 at 04:06 UTC
That was just a copypaste artifact I didn't bother to correct because it doesn't conflict with my convention anyway: all-uppercase BAREWORDS in my code are constants, except for the global filehandles predefined by Perl. (But I don't use bareword filehandles otherwise.) There has even been an actual occasion where the compile-time inlining of constants tricked me, and in inocuous enough looking Perl no less. (It involved external code invoked by do to load configuration mixed with predeclarations — you can probably guess what happened.) Makeshifts last the longest.	[reply]