Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday August 30, 2005
02:13 PM

"use constant" versus ReadOnly

[ #26512 ]

I just blew a nice chunk of time debugging the following problem:

use constant DEFAULT_ARGS => [qw/some data/];

...

unless (@_) {
    $self->{args} = DEFAULT_ARGS;
}

Later on in my code, I had this:

my $args = $self->args;
while ( defined (my $curr_arg = shift @$args) ) {
    # do something while blithely ignoring
    # the havoc we're wreaking
}

See the bug? The two accidentally coupled lines of code were 214 lines apart and appeared to be unrelated. That was a bugger to track down. The fix I used was to simple clone those args when needed, but my longer-term fix is to not use constants. Use ReadOnly:

#!/usr/bin/perl

use strict;
use warnings;
use Data::Dumper::Simple;
use ReadOnly;

use constant FOO => [qw/bar baz/];
my $data = FOO;
shift @$data;
print Dumper(FOO);

Readonly::Scalar my $foo => [qw/bar baz/];
$data = $foo;
shift @$data;
print Dumper($foo);

And the output:

$FOO = [
  'baz'
];
Modification of a read-only value attempted at constant.pl line 15


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

"use constant" versus ReadOnly 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • That doesn't seem very constant. Thanks for the tip.
    --
    Der Eisbär ist mein Freund.
  • Damian says the same thing in Perl Best Practices [oreilly.com]. And for pretty much the same reason.

  • I don’t know if the real code did something significantly different, but to me that’s just an example against consuming when you merely need to iterate. Or more abstractly: “avoid side effects.” I can’t remember ever having run into this sort of issue.

    I always cringe when I see people use shift on @_ – the only time I do that is when I really intend to modify the array, which boils down to my $self = shift; and precious little else.

    • I didn't show all of the code. There's a relatively common idiom of treating an array like a set of pairs, or an ordered hash:

      while (defined (my $key = shift @array)) {
        my $val = shift @array;
        # do something
      }

      In this case, this data needs to be represented as an array (hence my not using an ordered hash) except in this one odd corner case. Due to the nature of the code, this must always be the last step, so I didn't think destroying the array would be bad. I don't like it and it's definite

      • Ah – yeah, stepping through an array in steps of two is annoyingly complicated, and I admit to having used consumption to iterate in those cases as well:

        while( my ( $k, $v ) = splice @array, 0, 2 ) {
            # ...
        }

        And you’re right about C-style loops, I avoid them like the plague myself.

        Hmm, what would be a good idiom to establish for the purpose… maybe this?

        for my $i ( 0 .. $#array / 2 ) {
            my ( $k, $v ) = @array[ $i * 2, $i * 2 + 1 ];
            # ...
        }

        Cumbers

  • I guess the big question is, why make it a constant? The big reason, so far as I can tell, is compile-time optimisation.

    If you can define constants such that they will be compiled out, and in doing so make your code smaller, faster or simpler, then constants are a good thing.

    use constant UNIX = ...;

    eval UNIX ? 'END_UNIX' : 'END_OTHER';

    etc
    etc

    And so now you have smaller faster unix-specific code paths...
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.