It's (another) area where I find myself questioning the logic.

Why do Perl programmer's expect to be able to interpolate constants--into strings?

In most every other languages, you would need to interpret the value of a symbolic constant into a string using whatever their equivalent of (s)printf is. Admittedly, they also require you to do the same with variables, which Perl doesn't. But that's a convenience that Perl provides--yah Perl--not something that should be expected.

It is similarly impossible to directly interpolate a hash into a string without resorting to special measures:

perl> %hash = 1 .. 10;;
perl> print "%hash";;
%hash

perl> print "@{[ %hash ]}";;
1 2 3 4 7 8 9 10 5 6
[download]

and even then the results are pretty unsatisfactory.

And you can achieve a similar, complicated interpolation of constant subs into strings.

perl> use constant X => 12345;;
perl> print X;;
12345

perl> print "${ \ X }";;
12345

perl> print "@{[ X ]}";;
12345

perl> print 'stuff ' . X .' other stuff';;
stuff 12345 other stuff

perl> printf "stuff %s other stuff\n", X;;
stuff 12345 other stuff
[download]

Given the other benefits of constant subs:

perl> *X = sub{ 12345 };;
perl> *X = \12345;;
perl> print X;;
12345

perl> print "${X}";;
12345

perl> print "$X";;
12345
[download]

What Exporter supports? Autocopying function to scalar? Can you give me example how I can get $O_NONBLOCK using use Fcntl qw(some dirty Exporter magic);?

About modification of constants... yeah, you right. But I suppose this can be solved without performance loss by marking that scalar read-only in SV..? Anyway, I prefer read-write scalars to bareword subs. And if I'll see in somebody's code: $EINTR=123; than I will fire that guy immediatelly! :)

Do you also disallow soft references? ${$foo} = 123; is just as dangerous. As for autocopying a function to a scalar, that's not hard to do with a generalized import function. Learn a little symbol table magic - it's good for the soul. :-)

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

I don't understand your objection to "bareword subs". Perl understands them perfectly well if they are defined before they're called.

In practice, it's pretty rare that constants need to be interpolated, except maybe when debugging with print.

You can make $EINTR a constant with:

*EINTR = \4;
[download]

People are constantly (pun intended) being bitten by bareword subs not getting interpolated. A classic example is when they are used as a hash key, or on the left side of the => operator. And I often need them interpolated in strings, like SQL statements, which is really ugly with subs. I never use subs as constants for this reason.

You can make $EINTR a constant with:

*EINTR = \4;
[download]

but that kind of thing is not always portable between systems. Because the value must be a reference to a literal in source, afaik that would require some kind of source filter to get portability.

Out of curiousity, I'd like to understand better why you think this isn't portable? The value could also be a reference to a literal in an eval, not just the source itself. For example, here's a quick test I wrote (without the kind of robust error checking on the inputs that I'd write for a real module, of course.)

ConstantVars.pm

package ConstantVars;
use strict;
use warnings;

sub import {
    my $package = shift;
    die "Odd number of arguments to ConstantVars" if ! @_ % 2;
    my %constants = @_;
    my $caller = caller;
    while (my ($key,$value) = each %constants) {
        eval qq( *${caller}::${key} = \\"${value}" );
    }
}

1;
[download]

test_constants.pl:

use strict;
use warnings;

use ConstantVars (
    PI => 3.14159,
    VERSION => 1.01,
);

print "PI is $PI in version $VERSION\n";
[download]

Prints:

PI is 3.14159 in version 1.01
[download]

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Another option is the Readonly module, available on CPAN. I've never tried it, but some people recommend it.

I've read about it in Perl Best Practices book and I've tried it. It looks very promising (especially with Readonly::XS helper module).

But Devel::DProf show it's still use tie()ed scalar (and so call FETCH() on each scalar access) even with Readonly::XS installed.

This was sadly news, because I feel like with Readonly::XS it should just 'mark' SV as read-only and doesn't tie() it. :-(

but that kind of thing is not always portable between systems. Because the value must be a reference to a literal in source, afaik that would require some kind of source filter to get portability.

You lost me there. Can you give an example of this construct not being portable? I actually prefer this style of constants, so if there is a reason I should avoid it, I'd very much like to understand it.

-sauoq
"My two cents aren't worth a dime.";

Why not portable? Why source filters? I sure it as simple as:

eval q{*O_NONBLOCK = \\}.O_NONBLOCK;
[download]

This code work, and work even a little (1-20%) faster than usual scalar! It's portable and can be executed automatically in import() if it see user try to import $O_NONBLOCK instead of O_NONBLOCK.

it's much faster in many cases

    $ perl -MO=Deparse -e 'sub CONST(){1;} my $CONST = 1; print CONST,
+ $CONST'
    sub CONST () { 1 }
    my $CONST = 1;
    print 1, $CONST;
    -e syntax OK
[download]

package constants;
use strict;
use Exporter;
our @ISA = qw/Exporter/;
our @EXPORT_OK= ($FOO, @BAR, %HASH);
our $FOO = 1;
our @BAR = qw/A B C/;
our %HASH = (A=>1,B=>2);
1
[download]