Re: [PATCH 1/3] Extended ksh compatibility: namespace parameter syntax

[Sebastian Gniazdowski <sgniazdowski@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

I wonder, how far is this from supporting a nested arrays? Like arr[2][3]
or assoc[a][c]?

On Sun, 5 Mar 2023 at 09:11, Oliver Kiddle <opk@zsh.org> wrote:

> On 26 Feb, Bart Schaefer wrote:
> > The attached patch enables assignment of and reference to parameters
> > prefixed with ksh-style namespace syntax, e.g., ${.namespace.param}.
> > As yet, there's no special significance to use of this syntax, that
> > is, parameters having such a prefix are ordinary parameters like any
> > others, with the usual dynamic scoping rules, etc.  Each of namespace
> > and param must be an identifier in the original zsh semantics of
> > identifiers.
>
> I've been running this patch since you posted it and haven't found it to
> cause any problems as such. It also holds up to testing but with no way
> to assign to variables with a dot in their name, there's a limit to
> what's possible to test.
>
> My main concern is that in the absence of special significance to the
> syntax up-front it could be harder to add later. At least the
> documentation should warn so users should not be surprised if e.g, in the
> future, `local foo` will hide a ${foo.bar}. But every new module like ksh93
> could need reworking if the implementation changes so that this is a bar
> entry in a foo hash table instead of a foo.bar entry in a global hash
> table. I'm not sure how ksh implements the initial dot. It effectively
> blocks consecutive dots because you have to declare the parent first.
>
> Ksh uses dots both for namespaces and compound variables. Of the two,
> compound variables are definitely the most useful. The namespace { ... }
> syntax of ksh was not designed with the interactive nature of the shell
> being considered foremost. I like the aspect of hiding shell specific
> variables away below .sh - could also be good for .zle.
>
> I think it is a mistake to not make compound variables, namespaces and
> associative arrays merely different facets of the exact same underlying
> thing. I'd like to be able to dump variables out as json/xml/yaml and
> reimport them back without the loss of detail of which type they started
> out as.
>
> Oliver
>
>

-- 
Best regards,
Sebastian Gniazdowski

[-- Attachment #2: Type: text/html, Size: 2870 bytes --]