"Mark J. Reed" wrote:
> If I wanted to make a variable read-only, I would expect to do it
> by setting the read-only attribute on that variable, which I would
> further expect to do the same way I would set any other attribute at
> any other time. Orthogonality has its good points, even in Perl;
> you just shouldn't be afraid to veer off diagonally when it makes sense.
> I don't think close(var) makes sense.
"seal" has been suggested.
Currently nothing in perl enforces access besides lexical visibility
rules. Lexical visibility makes it possible to create read-only types
by tieing to classes where STORE is a no-op. Defining a read-only
implementation is trivial.
I'm experiencing Warnock's dilemma WRT my suggestion that the
make-read-only
operation, whatever it looks like, might return a coderef which could be
run
to unseal the variable/container, or might get not stored, indicating that
the item is permanently read-only and can be optimized as such.
As for read-only being an attribute, if attributes are compiler hints, how
do we set something to be read-only then? And we can't unseal a r-o item
without making a copy of it.
--
David Nicol 816.235.1187
Many wealthy people are little more than janitors
of their possessions. --Frank Lloyd Wright, architect (1867-1959)
