# Hello @all,
# I want to suggest readonly or 'is ro' declaration for variables. See:
readonly $temperature = db_temperature_of( $date_time_loc);
## much later
# It is *ensured* that $temperature is the original value from database!
my $result = important_decision( $temperature);
It can be very useful to ensure that a variable/container cannot be
modified after setting an initial value at *runtime*. Probably this will
become pretty popular if there is a easy way to do so. For example,
fetching data from database for analizing and reporting purposes only is
a very common task. It should be possible to protect the fetched data
actively. I think its a key feature to achieve higher security and reliability.
Even global variables lose most of its harm when they are readlonly.
Usual ways to keep the "original value" are not reliable.
In most cases (I assume) its: Just don't modify it! If it is important that
the value keeps unmodified: uppercase the name of the variable.
Well, sometimes the majority of my variables are considered to stay
unmodified. To uppercase them all is ugly but still not reliable.
Advanced technique: Use CPAN-Module Readonly. I use it, it's great!
But, whats missing is the capabilitiy to detect violations of the readonly
trait at compile time. Because of that, a program could fail to late.
The Synopses mentions a C<readonly> trait and also C<is ro> but its use
seems to be limited to code object like subroutines and subroutine
parameters. I have also recognized in S12 that there are ways to deal with
a VAR macro, but I dont feel that this fits my needs.
A declaration is better in many aspects. It tells the parser not to accept
any assignments in the source code after initialization on variables that
are declared 'readonly'. In other words, the total count of assignments in
the source code is one or none. (The latter could cause a warning.)
A binding of the variable inherits the readonly restriction. Hence it is
forbidden to use a readonly variable as a subroutine argument, when
the according parameter C<is rw>.
Thinking of the form, I see three ways:
(1) The best readable form is probably:
readonly $temperature; # lexical scope
(2) But this fits better in perl6 conventions:
my $temperature is ro; # lexical scope
our $weather is ro; # package scope
$*global_weather is ro; # global scope
(3) For those who work a lot with readonly semantics, this could be best:
readonly $-temperature; # lexical scope, twigil prevents all attempts!
I think form (2) should be possible for variables. And form (1)
should become syntactical sugar for
C<my $temperature is ro;>
What do you think? Does anybody agree?
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.