Actually, there are lots of ways to write that. Any expression that isn't just a bareword would work. $g{FOO()} is what I would have used. I've seen others write $g{&FOO} but I consider that a bad habbit as there are cases where that will get you into trouble.
You can also declare scalars as being constant (read-only) such as with ex::constant::vars (I seem to recall a more recent module that also does this, but a few quick searches didn't turn it up). These either toggle an internal bit that tells Perl to throw an error if you try to modify the value, or tie the variable to a package that does something similar. The first is a nice, clean way to make constants but it requires C code in the module.
Barewords are rather ambiguous in Perl and so how they get interpretted depends on a lot of things. So normally you avoid barewords. But, if you can arrange to have a bunch of subroutines predeclared, then invoking those via barewords will catch typos at compile time.
It'd be cool if you could get use strict to (optionally) treat subroutines more like it does variables so that a call to myRoutine() would be a compile-time error if myRoutine() hadn't already been declared. This change is very similar to what happened between old K&R C and ANSI C. Like all such strictures, it can be a pain to make happy (having to declare all subroutines before you go and use them), but it can also catch stupid mistakes must quicker, which is why strict.pm exists in the first place.
Add to that a warning if you declare a subroutine that shares a name with a built-in, and a whole boatload of problems will be solved.
- tye (but my friends call me "Tye")In reply to (tye)Re: use constant hash keys
by tye
in thread use constant hash keys
by grinder
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |