Re: Local variables overriding global constants

[Mike Frysinger]

On Wednesday 03 April 2013 21:38:19 Chet Ramey wrote:
> 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.

if we had an explicit `declare +r`, then it would be OK :)

i like languages which allow you to sprinkle sugar around to proactively 
protect you, but still allow you to override things in that 0.1% edge case.  
like C's const marker on a pointer -- the vast majority of the time, you want 
it to be const and to keep people from clobbering things, but every once in a 
blue moon, you want to ignore it and allow the store.

> >> 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.

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.

> > 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?

i meant it here to head off the naysayers who would propose my request was 
unnecessary based on the logic "if you don't know the code base, then you 
shouldn't be changing it".  i've seen this argument line before, but maybe i'm 
being unnecessarily pessimistic :).
-mike

signature.asc
Description: This is a digitally signed message part.