From: Bart Schaefer <schaefer@brasslantern.com>
To: Bart Schaefer <schaefer@brasslantern.com>,
Oliver Kiddle <opk@zsh.org>,
Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH 1/3]: Add named references
Date: Sun, 11 Feb 2024 10:14:40 -0600 [thread overview]
Message-ID: <CAH+w=7ateaqX5azdifTaFpJT6sX-fVhnEazgeYYXSWtJY8EQTw@mail.gmail.com> (raw)
In-Reply-To: <20240211070042.4j37hkgjjn3dfjqd@chazelas.org>
On Sun, Feb 11, 2024 at 1:00 AM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> One difference with ksh93: if the target variable was not set at
> the time of the "typeset -n ref=target", then when ref is
> assigned it may end up refering to a local target
Hm. I think I can prevent that from happening (it wasn't intentional)
but I don't know if it's feasible to actually create a new variable at
the original scope, because of the implemention as a linked list of
scopes for each parameter -- it's not clear how to insert a variable
into the middle of the list.
> It can be worked around with a typeset -g $1 before the typeset -n var=$1
Is that really sufficient? Might the -g not select the wrong scope if
the string $1 was passed down a couple of layers? Seems to me you
have to avoid re-using a variable regardless, especially if you do
typeset -n var=
(create what I've been calling a "placeholder") and then assign to var
in some nested scope. This may particularly be true of the "for var
in ..." special case for namerefs.
Something I forgot to mention before regarding "_zslurp_var" -- if
you're going to a assume "typeset -n" then you can also assume
namespace syntax e.g. ".zslurp.var"
But the zslurp I put in the distribution was also meant to be somewhat
backward compatible so I didn't use namrefs or namespaces.
next prev parent reply other threads:[~2024-02-11 16:15 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-06 2:21 Bart Schaefer
2023-02-08 3:45 ` Oliver Kiddle
2023-02-08 4:59 ` Bart Schaefer
2023-02-08 23:16 ` Bart Schaefer
2023-02-09 0:47 ` Oliver Kiddle
2023-02-09 2:01 ` Oliver Kiddle
2023-02-09 5:45 ` Bart Schaefer
2023-02-09 4:49 ` Bart Schaefer
2023-02-09 20:49 ` Oliver Kiddle
2023-02-09 23:07 ` Bart Schaefer
2023-02-11 3:04 ` Bart Schaefer
2023-02-11 3:55 ` Bart Schaefer
2023-02-11 5:36 ` Speaking of dangerous referents Bart Schaefer
2023-02-12 8:00 ` Oliver Kiddle
2023-02-12 8:34 ` Bart Schaefer
2023-02-11 7:02 ` [PATCH 1/3]: Add named references Oliver Kiddle
2023-02-11 7:45 ` Bart Schaefer
2023-02-11 23:43 ` Bart Schaefer
2023-02-11 23:45 ` Bart Schaefer
2023-02-12 7:38 ` Oliver Kiddle
2024-02-11 7:00 ` Stephane Chazelas
2024-02-11 16:14 ` Bart Schaefer [this message]
2024-02-11 16:42 ` Bart Schaefer
2024-02-18 3:26 ` Up-scope named references, vs. ksh Bart Schaefer
2024-02-20 21:05 ` Stephane Chazelas
2024-02-20 22:30 ` Bart Schaefer
2024-02-21 20:12 ` Stephane Chazelas
2024-02-29 5:16 ` Bart Schaefer
2024-03-01 18:22 ` Stephane Chazelas
2024-03-01 20:34 ` Bart Schaefer
2024-03-02 7:29 ` Bart Schaefer
2024-03-02 23:55 ` [PATCH] "typeset -nu" (was Re: Up-scope named references, vs. ksh) Bart Schaefer
2024-03-01 23:28 ` Up-scope named references, vs. ksh Bart Schaefer
2024-03-03 13:44 ` Stephane Chazelas
2024-03-03 19:04 ` Bart Schaefer
2024-03-03 20:27 ` Stephane Chazelas
2024-03-03 22:58 ` Bart Schaefer
2024-03-04 19:59 ` Stephane Chazelas
2024-03-05 1:05 ` Oliver Kiddle
2024-03-05 2:53 ` Bart Schaefer
2024-03-05 5:43 ` Mikael Magnusson
2024-03-05 6:30 ` Stephane Chazelas
2024-03-06 5:04 ` [PATCH] local vs. nameref scoping (was Re: Up-scope named references, vs. ksh) Bart Schaefer
2023-02-12 9:02 ` [PATCH 1/3]: Add named references Oliver Kiddle
2023-02-12 18:59 ` Bart Schaefer
2023-02-12 19:45 ` PM_* flags in zsh.h (was Re: [PATCH 1/3]: Add named references) Bart Schaefer
2023-02-12 21:01 ` Oliver Kiddle
2023-02-12 22:54 ` [PATCH 1/3]: Add named references Oliver Kiddle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH+w=7ateaqX5azdifTaFpJT6sX-fVhnEazgeYYXSWtJY8EQTw@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=opk@zsh.org \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).