Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: allow nameref -p
- X-seq: zsh-workers 53345
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Oliver Kiddle <opk@xxxxxxx>
- Cc: Zsh workers <zsh-workers@xxxxxxx>
- Subject: Re: PATCH: allow nameref -p
- Date: Sat, 1 Feb 2025 17:42:48 -0800
- Archived-at: <https://zsh.org/workers/53345>
- In-reply-to: <23591-1738394361.394912@8fpf.Pu7z.GtLu>
- List-id: <zsh-workers.zsh.org>
- References: <55798-1738150310.766410@Xzgb.tVwL.I4Vm> <CAH+w=7ZJBb=Ga7y6V-0bAo2r7FPb95ECRWd_syJz2od3BdG1jQ@mail.gmail.com> <23591-1738394361.394912@8fpf.Pu7z.GtLu>
On Fri, Jan 31, 2025 at 11:19 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> Much as with -r, typeset -nH ref or typeset -n +H ref should apply to
> the reference while typeset -H ref (where ref is a pre-existing
> reference) should apply to the referant (unless that's unset).
This is very easily accomplished in the code. It's a little messy to document.
> Bart Schaefer wrote:
> > I'm not offhand able to think of a case where +H makes sense, because
> > once the nameref exists with the -H flag applied you can only alter
> > the referent?
>
> By combining with -n you can still alter the reference.
Ah, good point.
> > As long as we're thinking about this, what about -h/+h ?
>
> Yes, I think so.
I'm waffling on this one. We don't currently have any default special
namerefs from modules, and if there were, what would it mean to
propagate that onto a local? That the local also becomes a nameref
even if not declared as one?
> -g/+g maybe too. But that might need some thought for each combination
> of reference/referent being unset/unspecified/local/global/private.
-g/+g already work and are mentioned in the doc. There are some
potentially surprising side-effects of using -g without -u, but
nothing that causes valgrind to burp.
> > Rationale for that is in a code comment:
> > /* It's generally unwise to mass-change the types of
> > * parameters, but for namerefs it would be fatal */
>
> If that's explicitly singled-out rather than part of a catch-all
> condition, the error message might be clearer.
I'll look at some way to change this without repeating the error for
every parameter name that matches the pattern.
Should it repeat for every option that isn't allowed if the user has
specified a whole raft of option flags?
> > I think we do have some past examples of e.g.
> > using -m to create function-local coverages of all the matching
> > parameter names.
>
> Looking in the zsh sources, we have only test cases doing that.
>
> Was the bulk function-local coverage case you remember perhaps just a
> hypothetical toy problem for an answer on zsh-users?
Yes, it's probably from a question on-list, but not necessarily a toy
... maybe Sebastian's module loader, or something like that?
> typeset +m could safely be changed but only doing +m would be a bit
> weird.
I don't think +m applies type changes even now, using +m is already
"weird" in several ways.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author