Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: allow nameref -p
- X-seq: zsh-workers 53339
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Oliver Kiddle <opk@xxxxxxx>
- Cc: Zsh workers <zsh-workers@xxxxxxx>
- Subject: Re: PATCH: allow nameref -p
- Date: Wed, 29 Jan 2025 16:01:14 -0800
- Archived-at: <https://zsh.org/workers/53339>
- In-reply-to: <55798-1738150310.766410@Xzgb.tVwL.I4Vm>
- List-id: <zsh-workers.zsh.org>
- References: <55798-1738150310.766410@Xzgb.tVwL.I4Vm>
On Wed, Jan 29, 2025 at 3:31 AM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> ksh93 allows nameref -p. So p not being listed as an option was probably
> an unintended omission, or? It works fine when added.
Not exactly unintended, but not really thought about either.
> Was there a good reason not to allow -H/+H with typeset -n?
Partly that -H means something different in ksh, but mostly for the
same reason that nameref was given only -u and -r. It was easier to
blanket exclude everything that I wasn't specifically thinking about
adding.
Given that by default all dereferences of a named reference instead
examine the referent, applying -H to a named ref should instead hide
the value of the referent? Which it does (currently) if you
separately typeset -n and then typeset -H. I guess that's also true
of -u and -r, so making the "simultaneous" application of -n and -H
have a different meaning would probably be fine.
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?
As long as we're thinking about this, what about -h/+h ?
> Combining -m with -n results in an "invalid reference" error even when
> converting the relevant parameters would otherwise work.
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 */
> I think something like typeset -im H\* should have the behaviour of
> printing matching parameters that already have the designated type and
> not attempt to convert the type of all parameters that match
Per above excerpted comment, I completely agree, but I wasn't prepared
to alter that existing behavior in the same patch set that introduced
this new behavior. I think we do have some past examples of e.g.
using -m to create function-local coverages of all the matching
parameter names. Again it was easier to blanket disallow -nm than to
try to figure out all the combinations that would otherwise work.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author