$ perl -e'$foo=\"I am immutable"; $$foo="fie!";'
Modification of a read-only value attempted at -e line 1.
$
[download]

Is that what you want?

Update: Better yet,

$ perl -e'*foo=\"I am immutable"; $foo="fie!";'
Modification of a read-only value attempted at -e line 1.
$
[download]

And for lexical variables, you can use the Lexical::Alias module:

$ perl
use Lexical::Alias 'alias_r';

my $s;
alias_r \"I am immutable", \$s;

$s = "fie!";
^D
Modification of a read-only value attempted at - line 6.
$
[download]

Update: I don't think it's documented behaviour. It just happens to work, probably because of the way the module is implemented (I am by no means a perlguts expert - and I haven't studied the source). Here's a snippet from the module documentation:

alias_r(\src, \dst)

Makes dst (which must be lexical) an alias to src (which can be either lexical or a package variable). src and dst must be the same data type (scalar and scalar, array and array, hash and hash). This is not exported by default.

Of course you can play by the rules:

[...]
my $s;
{
  local $tmp;
  *tmp=\"I am immutable";
  alias_r \$tmp, \$s;
}
[...]
[download]

Did you check CPAN for a module? If there isn't one, you could write one yourself to use the tie mechanism to subvert changing the value of the scalar. perldoc perltie

Here's a quick implementation (untested):

#!/usr/bin/perl

package ConstScalar;

sub TIESCALAR {
   my $class = shift; my $val = shift;
   return bless \$val, $class
}

sub STORE { }
sub FETCH { my $self = shift; return $$self; }

package main;

my $pi;
tie $pi, 'ConstScalar', 3.14159265358979323846;
print "$pi\n";
$pi = 5;                # no effect
print "$pi\n";
[download]

But the user still can do an UNTIE!

package main;

my $pi;
tie $pi, 'ConstScalar', 3.14159265358979323846;
print "$pi\n";
untie $pi ; #### NOW AS A NORMAL SCALAR
$pi = 5;                # effect!
print "$pi\n";
[download]

But thanks for the idea! ;-P

Graciliano M. P.
"Creativity is the expression of the liberty".

This is perl mate, no matter what you do, it is extremely likely that anyone else writing code that uses it will be able to basically anything they want to it. Theres no harm in trying to create some guidelines and trying to enforce them at a basic level, but if they don't want to deal with them they can find a way around them. Think of it like 'use strict', its mostly helpful to catch mistakes but if you really need to do something it won't allow you can turn it off.

Internals::SvREADONLY($your_scalar, 1);
[download]

The user? The user doesn't use Perl, the developer uses Perl.

Why do you want a scalar and not a sub?

Anyway, others have already suggested assigning a reference to a literal (a literal is a readonly scalar variable, really!) to a typeglob, but there is a way to turn the readonly flag on during runtime, using xmath's Spy module, which unfortunately he never finished.

use Spy;

my $foo = 123;
spy(\$foo)->readonly = 1;
$foo++;  # Modification of a read-only value attempted at - line 5.
[download]

I just have looked the module Spy, and the author have implemented the module B::More, that can set the readonly flag.! Thanks for the tip.

But I saw that already exists a module for that, Internals, that let you handle this things. Thanks monks!

Graciliano M. P.
"Creativity is the expression of the liberty".

> The user? The user doesn't use Perl, the developer uses Perl.

Duh! How a bout another Perl developer using the enverioment that I'm developing?!

Well, I say that because I work building softwares for developers, not for end users.

Graciliano M. P.
"Creativity is the expression of the liberty".

Duh! How a bout another Perl developer using the enverioment that I'm developing?! Well, I say that because I work building softwares for developers, not for end users.

It is very un-perlish to lock something. You don't know what creative solutions others invent using your code, and I think it's better to free your code and let others use your code much the way you use Perl. Locking a scalar makes no sense. It's probably a sign that you need another "user" interface (API). Maybe you want OO with a protected property. Perhaps you just need a simple function that returns a value. But I seriously doubt you really need a scalar that is readonly.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Tie::Scalar::RestrictUpdates is the first thing I found. Look at the POD, and you'll see that when you tie it, you tell the class how many times you'll allow that scalar to be updated or changed. After that number is reached (could even be 1 if you want), the scalar can no longer be modified.

You're worried that someone would untie it, but realistically there isn't much someone couldn't do if he/she wanted. Someone could even completely rewrite your code, or abandon it altogether because of inflexibility. You can't really stop a developer from having his way with your code, if he has access to it. You may contrive an elaborate means of preventing a variable from being changed by a developer, but you can't lock him out of your code entirely, while at the same time giving him access to your code.

Update: As sauoq++ and duff++ point out, my brain was in neutral:(

The are several ways of approximating it, but the easiest to really create a simple, readonly scalar is Scalar::Util::readonly().

It is even part of the standard distribution in the most recent versions.

How will that help? Scalar::Util::readonly() is for checking whether a scalar is readonly, not for creating a readonly scalar.

I'd second the method that Zaxo suggests in his update. That's the "old-fashioned" way to create constants. Here's how to use Scalar::Util::readonly() to prove it works nicely...

perl -MScalar::Util=readonly -le '*f = \"foo"; print readonly($f)'
8388608
[download]

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

Doesn't Scalar::Util::readonly() just tell you if the scalar is readonly or not? I.e., you can't create a readonly scalar from it.

duff

• Copyright your code
• Hire a DMCA lawyer
• Sue anyone who "reverse engineers" this scalar

But seriously...in Perl, these things are best handled as a matter programming policy, not language mechanics.