[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Local variables overriding global constants
From: |
Chet Ramey |
Subject: |
Re: Local variables overriding global constants |
Date: |
Wed, 03 Apr 2013 21:38:19 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 4/3/13 12:31 PM, Mike Frysinger wrote:
> sounds like the fundamental limitation is that the person writing the code
> can't declare their intentions. after your compromise, they now can. if you
> follow the convention of putting all code into a main() func (rather than
> executing code in global scope), you can do:
> #!/bin/bash
> ... declare all your funcs ...
> main() {
> declare -gr VAR=value # i really want this to stay read-only
> declare -r FOO=value # i'm ok with people overriding this in funcs
> ...
> }
> main "$@"; exit
>
> having this flexibility just came up in the Gentoo world and i'm glad i saw
> this thread as now we have a technical solution :). we have some vars we
> want
> to be read-only and not overridable, but we have a few we want to default to
> read-only but allow people to localize.
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.
>> The current behavior is a compromise. Compromises always come back to
>> bite you because the inconsistencies that result are more trouble than
>> the flexibility they offer is worth.
>
> 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.
> i'm not interested in debating the "you should be familiar with the code
> base"
> as that's not being realistic. large code bases in the open source world, by
> their nature, accept drive by commits and accidents happen.
Are you sure you meant to include this in your reply? Were you replying to
some other message at the same time?
Chet
- --
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlFc2YQACgkQu1hp8GTqdKuMegCdEd0mvqVKFAd02enCZV8jDDAx
C1oAoIeDK0b9D62M300q/bmPKvnJbear
=Gc5C
-----END PGP SIGNATURE-----
- Re: Local variables overriding global constants, (continued)
- Re: Local variables overriding global constants, Chris F.A. Johnson, 2013/04/03
- Re: Local variables overriding global constants, Pierre Gaston, 2013/04/03
- Re: Local variables overriding global constants, Chris F.A. Johnson, 2013/04/03
- Re: Local variables overriding global constants, Pierre Gaston, 2013/04/03
- Re: Local variables overriding global constants, Chet Ramey, 2013/04/03
- Re: Local variables overriding global constants, Mike Frysinger, 2013/04/03
- Re: Local variables overriding global constants,
Chet Ramey <=
- Re: Local variables overriding global constants, Mike Frysinger, 2013/04/04
- Re: Local variables overriding global constants, Chet Ramey, 2013/04/04
- Re: Local variables overriding global constants, Mike Frysinger, 2013/04/04
- Re: Local variables overriding global constants, Chris F.A. Johnson, 2013/04/03