in reply to Using Constants in Perl

Readonly and "use constant" aside, what's wrong with the plain old:
# The following are constants my $FOO = "BAR"; my @BAR = qw/This is a constant array/; my %HASH = (1=>2, 2=>3);

Replies are listed 'Best First'.
Re^2: Using Constants in Perl
by Fletch (Bishop) on Feb 28, 2006 at 19:19 UTC

    They're not constants (in that they're modifiable)?

    They won't be inlined during compilation?

    That if you don't see that one comment line (because you started editing waaaay deep in the file) you could introduce bugs in other code because you inadvertently modified said "constant"?

      I'm aware of that. The reason I'm asking this is whether this is a theoretic/purist concern or a practical concern. "use strict" is useful because it's very common to make the kind of mistakes it prevents; I don't remember the last time I had a bug because I modified a constant (e.g, something named $CONST_DATABSE_NAME)

        I've seen it happen.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

        It's a very practical concern. Sure you are perfect and will never modify it, but you've got to think about the inevitable slack-jawed yokel maintenance programmer that will follow you. Three years hence, Cletus is going to bollix things up bad because he can modify it.

        It's like the story (probably apocryphal; I want to say I heard it back in college in a compilers class) of the early Fortran compiler that allowed constants on the left hand side of an assignment to be modified, changing the value in the constant pool (I think it was on an architecture that didn't allow immediate values; everything had to be loaded to registers from RAM, so even things like "1" and "4.20" were sitting somewhere in memory). Sure nobody will be silly enough to intentionally set 3 = 2, but accidents can happen (c.f. Murphy) and then someone has real fun tracking down where the really large values of 1 and 1 are coming from when suddenly 1 + 1 EQ 3 is true.