From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from zero.zsh.org (zero.zsh.org [IPv6:2a02:898:31:0:48:4558:7a:7368]) by inbox.vuxu.org (Postfix) with ESMTP id 2E18724B89 for ; Sun, 10 Mar 2024 13:14:48 +0100 (CET) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1710072888; b=eN+UnwaNUSrwh7uElt0XZpfDCa+QIm9aLtrMlLabWzT1ySSEnHsdP1/3IqLIobGWaQ2yEQsqwN Ef7PVS5I3Y59EPJD7/kvzIzn0LgE3wlpn/WJAuH/BqTKu9M8C/JUfekOqDJ/rM0+XrlKi869TA JCGs7JiGkKpAnN9OHuby0O0Ynv9J8Q6mHsUDApSF/XhTtjern7zsZWJ9iELirwK5VgDvVpp/kc f8UJIFmI+hkxK4Mzsshsj4Cu0Oi1Lqdva7cPi+nOf9BwU8vwhBAkkP3NgJKJRiCOgMFlp+N7ie OYZhRHmgI7cKZ9KpzXJtnzP39nxEdlxxu/KPDx3PFlG/mQ==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (relay5-d.mail.gandi.net) smtp.remote-ip=217.70.183.197; dmarc=none header.from=chazelas.org; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1710072888; bh=SI35XKWFSphWZLZKWS17+eDaOgsvM54JcgfgRqUS/iA=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:DKIM-Signature; b=NpHUGWPGz3AItGtZR9dX0glNFuVi6Y9w8cw6rLMuVLglq2a/32plkNH4WVm2rqshSybK+XB1/m WEdUDMPyBMbjc4tyMU27KVvJULi1srQyBzx5R/+VAE8GdvneMYKooUVGjYhhgPOQ4drsUnVc3Q MULluNHZBiFErhZMKeqgsIRwlQKRTApE9v8kKjf2dAN0gBPOwbFZow4IPzFhQkI3eg/WQc2gfh Ixw6A54jHd3sIqJcbTYsPhov6tYBHOm+xKRAjwoJxhEpis0/IB1zxFKCufVlJEaxvx6U1T8Zrv MCYIa2D4Gus4W0Ai5w25m4uGyhawcJvThZGckDrXkN/Tzw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=6hBVXkP0N8PVsnC35IUiU88EkU2qMEWmOZkTag65kWg=; b=BLIvcLRjIAdh7rv9V7A+tgTYny UDBJ/fd82CLAAM3qqaKJYi0+2J8QXnzEwGrcXqHuT4XON84bKpIXevzo0AdYYgzBWu4dG3rTNwh4t WbtpOzF3EldlGZ/9SgQvxTYOJv1mxdY8eTz+tl7aZSV4G2eUZV/OjVwbcbO0ozYWpyeT8UfSJoqzA UK1MoTuJ/279JpnkhJcSv09wUYYd20mSRo2xmN6CkyHv5HSXEXD7wjV0L4hibOBWJqOSPQF3muwJZ AoxegvGU0uKIbAzFTgBa/CUIPmwk/4lOQql6/xR7YXe5ATFX+/EtytNGgweoOxm998fTealCMtoMa 4OtkpEOw==; Received: by zero.zsh.org with local id 1rjI4k-0000St-G9; Sun, 10 Mar 2024 12:14:46 +0000 Authentication-Results: zsh.org; iprev=pass (relay5-d.mail.gandi.net) smtp.remote-ip=217.70.183.197; dmarc=none header.from=chazelas.org; arc=none Received: from relay5-d.mail.gandi.net ([217.70.183.197]:37205) by zero.zsh.org with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1rjI41-000Pit-La; Sun, 10 Mar 2024 12:14:02 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id B4EA41C0002; Sun, 10 Mar 2024 12:13:59 +0000 (UTC) Date: Sun, 10 Mar 2024 12:13:59 +0000 From: Stephane Chazelas To: Bart Schaefer Cc: Zsh Users List Subject: Re: Why would I use .namespace.myvar? Message-ID: <20240310121359.iuhmf5renmuf6y4z@chazelas.org> Mail-Followup-To: Bart Schaefer , Zsh Users List References: <20240309143036.xwqm234mtu5wqh2r@chazelas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-GND-Sasl: stephane@chazelas.org X-Seq: 29724 Archived-At: X-Loop: zsh-users@zsh.org Errors-To: zsh-users-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-users-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: 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