Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: LOCAL_VARS option ?
- X-seq: zsh-workers 40387
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- Subject: Re: LOCAL_VARS option ?
- Date: Thu, 19 Jan 2017 07:47:53 -0800 (PST)
- Cc: zsh-workers@xxxxxxx
- In-reply-to: <20170119065408.GA5534@fujitsu.shahaf.local2>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20170119065408.GA5534@fujitsu.shahaf.local2>
- Reply-to: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
On Thu, 19 Jan 2017, Daniel Shahaf wrote:
> Phil suggested on IRC a LOCAL_VARS option that has the effect of making
> all newly-declared variables local; e.g.,
>
> % unset x y
> % () { setopt localvars; x=42; typeset -g y=43 }
> % echo $+x $+y
> 0 1
> %
>
> I'm attaching a proof of concept patch (work in progress; see top of the
> attachment for known issues), but WDYT of the the general concept?
I believe we discussed this idea once before, and rejected it on several
grounds. However, I can't find the thread at the moment. From memory:
1. Once the option is set, it affects all functions called by (whether
directly or indirectly) the one that set the option. If set at the
top level, this results in a significant change in semantics.
2. Unlike local_options, which applies when the function exits, this has
to be applied when the parameter is created. There's already a
mechanism to accomplish this, namely to declare the parameter. The
only reason to need local_vars is to change the semantics of *other*
functions [see (1)], which is generally a bad idea.
3. If unset by a called function in order to prevent (2) and that called
function is NOT also using local_options, it can break the calling
function in unpredictable ways.
4. The semantics of the other LOCAL_* options are already problematic in
obscure ways, but just because we're stuck with them doesn't mean we
should add another potentially problematic variation.
5. (New since the last time this was discussed) The type of problem this
"solves" is generally better addressed by WARN_CREATE_GLOBAL so that
proper use of parameter declarations can be applied.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author