in reply to Top 10 things to read when your flight is canceled

Some of those are definitely on my list of things to read.

++Class::Accessor and DBIx::Class.

I am not a big constant fan however. I went through a phase (well, probably about 2 years) of using them, but they can be fiddly at times, especially if you use them for complex data structures. You often end up with something like:
print "I have " . FOO()->{APPLES} . " apples".
which to me is just ugly, and gets unreadable pretty quickly, especially if you have constants in different packages.

Besides that, I realised there's actually nothing stopping you modifying the values. Like most things in Perl, it's really just a convention. If that's the case, I'd rather just use uppercased variable names, which is a pretty widely used convention, and not as messy as the pragma.

Replies are listed 'Best First'.
Re^2: Top 10 things to read when your flight is canceled
by rodion (Chaplain) on Mar 13, 2007 at 21:55 UTC
    In Perl Best Practices (Ch. 4) TheDamian recommends "use Readonly" instead of "use constant", both because it prevents further modification of the value, and because Readonly gives your constants the syntax properties you would expect to go with their having a sigil.
      The disadvantage to Readonly is that it isn't optimized away, if it was possible. For example:
      use constant DEBUG => 0; print STDERR "foo = $foo\n" if DEBUG;
      The second statement gets optimized away. But in
      use Readonly; Readonly::Scalar $DEBUG => 0; print STDERR "foo = $foo\n" if $DEBUG;
      the last statement is not optimized away, and the test is indeed performed every time the statement is encountered.

      Even worse: a Readonly variable is a tied variable, so the test will be slower than it would have been if it wasn't Readonly.

Re^2: Top 10 things to read when your flight is canceled
by bennymack (Pilgrim) on Mar 14, 2007 at 12:44 UTC
    printf "I have %s apples", FOO()->{APPLES};