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

[Bart Schaefer <schaefer@brasslantern.com>]

On Fri, May 19, 2023 at 7:06 PM Phil Pennock
<zsh-workers+phil.pennock@spodhuis.org> wrote:
>
> AFAICT, in zsh, .a.b=c is assigning to var b in namespace a, while a.b=c
> is setting the b attribute of the compound variable a.

As presently implemented, there's no difference.  The latter is
supported by the parser but should be considered a reserved syntax;
some sort of compound variable feature is a possible future
application.

> I think that you can use a set of namespaces for subsystems and have
> bound names (aliases) from the main namespace to those for existing
> behavior, unless an emulate directive says to be particularly strict.

Yes, that's one of the possible uses of named references.

> Then you could have the completion system switch away from littering the
> main namespace with _foo functions, by moving completion functions into
> the namespace

Function names already are (always were) more flexible than variable
names.  We could have used ".comp.foo" instead of "_foo" from the
beginning, if that had been thought more important than brevity at the
time.  In retrospect it might have been nice to have distinct
name(space)s for "completers" vs. "completion functions".

The missing bit for functions is that a leading "." doesn't hide the
function from the "functions" command the way it hides variables from
"typeset".

> and all sorts of cache variables there, which has the
> added bonus that leaks in user written completions won't pollute the
> main namespace.

Yes, there are a number of places where globals could benefit from hiding.