Re: Why would I use .namespace.myvar?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Mar 9, 2024 at 6:30 AM Stephane Chazelas <stephane@xxxxxxxxxxxx> wrote:
>
> (not sure which of zsh-users or zsh-workers is best suited for
> this discussion, I'm picking zsh-users for now but please feel
> free to move to zsh-workers in follow-ups).

For -users who haven't been following the -workers list, namespaces
are a new feature appearing in the next release (version number TBD).

Reordered some excerpts below to group responses better ...

> - "." can now be used in the name of a variable, though with
>   limitations:
>   * .foo, foo., a.b, .a.b, a.1, .a.1x are OK, but not
>   ..foo, .foo., .1.a, foo.., a.b.c, .a.b.c
>   * you can refer them as ${a.b}, but not $a.b (understandably)

So far so good.

> - the ones starting with . are hidden from the output of "set"/"typeset"

Yes.

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

>   and there's no way to unhide them even with typeset -h

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"

> It's always been possible to use . (or any character or
> non-character, even the empty string) in function names, so
> functions are not covered in the new feature.

Also correct.

> In particular, as noted in the doc, there's no support for
> ksh93's:
>
> $ namespace foo { a=1 b=2 c=3; }; echo "${.foo.a} ${.foo.b} ${.foo.c}"
> 1 2 3
>
> 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.

> So why would I use a ${.mynamespace.myvar} over
> $_mynamespace_myvar, $ːmynamespaceːmyvar or $𐅂mynamespace𐅂myvar
[...]
> for my variables which I would want namespaced?
>
> I could also hide my _mynamespace_myvar variable with typeset
> -h if I wanted to.

The -h option of typeset does not hide the name, it hides the
"specialness" of a parameter.  If you apply it at the top level (which
most autoloaded specials do), then in order to make a local with the
same properties you must do e.g.
  typeset +h parameters
to get a local that behaves like the global autoloaded $parameters
association.  If there's a global special like $status that does not
use -h, then
  typeset -h status
gives you a local that doesn't mirror the global.

The -H option hides the value, but does not hide the name.  So only
using a namespace hides the whole thing.

> AFAICT, that doesn't give me more guarantee of avoiding clashes,
> and that means I have to use those braces.

Given dynamic scoping, the only thing that really comes close to a
guarantee of avoiding clashes is zsh/param/private, so that is true.

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

> How about nested namespaces?

They don't work / aren't allowed.  Each "namespace" keyword starts a
new global namespace even if used inside another namespace
declaration.

> Is using ${.foo.bar} going to be recommended going forward for
> namespacing variables in user-contributed code shipped with zsh?

Probably only for user-contributed code that needs to maintain global
state for re-entrancy, but I wouldn't expect it to be more than a
recommendation.

OTOH for example Oliver is already doing that.

> Is the intention to reserve those for code included with zsh to
> users can be sure not to clash with the zsh ones if they don't
> use them?

It's the intention to reserve some namespaces, the way ksh reserves
the ".sh" namespace, yes.  So far there's only been minimal discussion
of which names would be included.  Possibilities are things like
".zsh", ".zle", ".compsys".  The mkshadow (_shadow) utility has
already co-opted ".shadow", and Oliver's "hlgroup" module is using
".zle".