-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 4/4/13 12:34 AM, Mike Frysinger wrote:
>> Yes, this has come up before. It's one reason to keep the compromise in
>> place. But is FOO being readonly in the function where it's declared and
>> not being able to unset it enough rationale to continue to support these
>> semantics? One problem is the one you point out below.
>
> if we had an explicit `declare +r`, then it would be OK :)
If you have declare +r, you might as well not have readonly variables
at all.
>>> would it be possible to enable a mode where you had to explicitly
>>> `declare +r` the var ? being able to "simply" do `local FOO` allows
>>> accidental overriding in sub funcs where the writer might not have even
>>> realized they were clobbering something possibly important.
>>
>> It's an idea, but I don't really like the idea of making declare +r, which
>> is disallowed everywhere else, do something in just this one special
>> context. Maybe another flag. I'll have to think on it.
>
> is there a reason for not just allowing `declare +r` everywhere ? seems like
> the proposal fits nicely into the existing system (although you've said
> you're
> not terribly happy with said system): you can do `declare -gr` to get perm-
> read only before, or you can do `declare -r` to get read only by default
> while
> still allowing sub functions to override if they really want.
The idea, I believe, behind `readonly' is that you want constants. There's
no reason to even offer the functionality if you can easily make things
non-constant.
Chet
- --
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlFdjEIACgkQu1hp8GTqdKuJVQCfdFjaMdWkfgeU6jndmQc2Brqm
q8gAn0JmIZFGHlL4OXSKl3NLtCXrUIK6
=wkSH
-----END PGP SIGNATURE-----
