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