Re: Why would I use .namespace.myvar?

[Stephane Chazelas <stephane@chazelas.org>]

2024-03-09 14:58:10 -0800, Bart Schaefer:
[...]
> >   (and not having them starting with .
> >   is discouraged, presumably because that would conflict with
> >   ksh93's compound variables which zsh might want to support in
> >   the future?)
> 
> Something like that.  Ksh has a couple of special meanings of
> ${var.func} in addition to compound variables.  It's all rather messy
> if you ask me, but we might pick and choose.

Thanks Bart for the detailed feedback!

Yes, all of the namespace, compounds, types, disciplines, nested
assoc/array in ksh93 give an "experimental" vibe and of being
unfinished and/or not fully thought through.

A lot of it is also not hugely useful in a shell, and is not
documented much and I don't expect many people have used even
half of it which likely also explains why it's still quite bogus.

I've just raised https://github.com/ksh93/ksh/issues/727 this
morning about "echo" not working in namespaces making me
thinking there can't be many people using those namespaces there
(even if we take into account that "print" is preferred over
"echo" in ksh)

See also https://github.com/ksh93/ksh/issues/325 and more
generally
https://github.com/ksh93/ksh/issues?q=is%3Aissue+is%3Aopen+namespace
there.

[...]
> That's also correct, except that -h doesn't mean the same thing at
> all, so it's not really a meaningful "even with".
> 
> > except with things like:
> >
> >   typeset -p ${(kM)parameters:#.*}
> 
> Also "typeset -pm pattern"

Thanks, that makes it significantly easier to list variables in
a namespace.

[...]
> > Is there a chance that ksh93's namespace keyword be added in the
> > future?
> 
> Yes, adding the namespace keyword is planned, probably for a
> next-after-next release when we have some more real-world usage of the
> current code.
[...]
> > Would the fact that function names have been allowing .
> > since forever or that .foo or .foo.1 are allowed not be a problem?
> 
> There's a small chance of backward-compatibility issues if someone is
> using function names beginning with a dot, yes.  Names containing a
> dot are only an issue if the part before the dot is the same as the
> name of a parameter
> 
> We'd have to make some decisions about .foo.1 and similar with respect
> to assignments -- it's not a large problem for expansions given that
>   namespace foo { echo $1; }
> "fails upward" to the positional parameter $1 if ${.foo.1} does not exist.

Would it be correct to say that the main goal for introducing
namespaces then would be to tidy-up the output of typeset -p/set
for all the subsystems of zsh written in zsh (completion,
zle...) and third party plugins?

Wouldn't having the .space.var variables and namespace {...} in
two separate releases be counter-productive as plugin authors
would first change their code from:

myplugin() {
  myplugin_myglobal=whatever
  ...
}

To:

myplugin() {
  .myplugin.myglobal=whatever
  ...
}

in 6.0 (say) as an improvement to limit the typeset output
pollution.

Only to change it again to:

myplugin() namespace myplugin {
  myglobal=whatever
  ...
}

(or however namespace is going to be meant to be used then)

In 7.0

(and possibly have to maintain 3 versions for zsh 5, 6, 7).

If it's going to be done in a staged way, it seems it would be
safer to start strict and relax later rather than the other way
round to limit the risk of breaking backward compatibility in
the future.

Like if we allow ${.space} and ${.space.1} now but we find that
it prevents adding namespace {...} in the future, it will be
harder then to say "oh you can't do that anymore".

Deferring the introduction of the "namespace" keyword (which
sounds to me like it's the key missing part for the feature to
be really useful) sounds risky unless we already have a clear
idea of how it's going to work as we might find that the whole
design and possibly user API would need to be rethought (like
the namespaces would need to be declared in advance like in
ksh93).

(having said that, I've not given it much thought myself so my
apprehensions may very well be baseless).

-- 
Stephane