zsh-users
 help / color / mirror / code / Atom feed
From: Stephane Chazelas <stephane@chazelas.org>
To: Zsh Users List <zsh-users@zsh.org>
Subject: Why would I use .namespace.myvar?
Date: Sat, 9 Mar 2024 14:30:36 +0000	[thread overview]
Message-ID: <20240309143036.xwqm234mtu5wqh2r@chazelas.org> (raw)

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

I didn't read the initial discussions around the introduction of
namespaces in the current development version of zsh, but from
what I can tell it means:

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

- the ones starting with . (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?) are hidden from the output of "set"/"typeset"

  and there's no way to unhide them even with typeset -h, except
  with things like:

  typeset -p ${(kM)parameters:#.*}

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.

And unless I'm missing something, that's it.

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

So why would I use a ${.mynamespace.myvar} over
$_mynamespace_myvar, $ːmynamespaceːmyvar or $𐅂mynamespace𐅂myvar
(which do work on GNU systems at least as ː, 𐅂 as well as
hundreds of other characters which look appropriately shaped for
the purpose are classified as alpha (in locales whose charmap
have them) there) for my variables which I would want namespaced?

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

I could also hide my _mynamespace_myvar variable with typeset
-h if I wanted to.

Is there a chance that ksh93's namespace keyword be added in the
future? Would the fact that function names have been allowing .
since forever or that .foo or .foo.1 are allowed not be a problem?
How about nested namespaces?

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

Thanks
Stephane
 


             reply	other threads:[~2024-03-09 14:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-09 14:30 Stephane Chazelas [this message]
2024-03-09 22:58 ` Bart Schaefer
2024-03-10 12:13   ` Stephane Chazelas
2024-03-10 20:08     ` Bart Schaefer
2024-03-10 22:16       ` Ray Andrews
2024-03-10 22:45         ` Lawrence Velázquez
2024-03-10 23:02           ` Ray Andrews
2024-03-10 23:53             ` Mark J. Reed
2024-03-11  2:22               ` Ray Andrews
2024-03-11  2:35                 ` Bart Schaefer
2024-03-11  2:50                   ` Ray Andrews
2024-03-11  7:53               ` Stephane Chazelas
2024-03-10 22:48         ` Bart Schaefer
2024-03-10 23:14           ` Ray Andrews

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240309143036.xwqm234mtu5wqh2r@chazelas.org \
    --to=stephane@chazelas.org \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).