Re: PATCH: allow nameref -p

[Oliver Kiddle <opk@xxxxxxx>]

Bart Schaefer wrote:
> > 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

It has a use that could only be meaningful for a referent and which is
probably only meaningful with their rather dead UWIN software.

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

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

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

> As long as we're thinking about this, what about -h/+h ?

Yes, I think so.

-g/+g maybe too. But that might need some thought for each combination
of reference/referent being unset/unspecified/local/global/private.

> > 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 */

If that's explicitly singled-out rather than part of a catch-all
condition, the error message might be clearer.

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

I fully understand why you kept things simple for the nameref addition
change. But, can we reasonably change that behaviour?

Looking in the zsh sources, we have only test cases doing that.

Test/E03posix.ztst and Test/B02typeset.ztst
13:  typeset -h +g -m \*

The current behaviour would still be possible by using something like
${(k)parameters}.
typeset +m could safely be changed but only doing +m would be a bit
weird.

Was the bulk function-local coverage case you remember perhaps just a
hypothetical toy problem for an answer on zsh-users?

Oliver