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 3146F297C2 for ; Sat, 9 Mar 2024 23:59:05 +0100 (CET) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1710025145; b=NsrJ/acZHHIxLQqBLQg8y/fi6cmGzwNStigPOca4Xl+UKqUHhS5Znj2uBNvEJBt49+h758nGZw UhmncufDfxLR1aVApJqft2qd6hdencWZKGNdElGnHUu8oFT6jdRBsg66qtdzOSjHJ5T2OPmsoi 8G80CBo/NxAogkMccBES6aNj4E3WEWy04mFVjOFtVCKdQGsEgDuI615GaYE/CL42KCzXCSgBu2 vnV3Sgdil71xAWKNIpF9Cgk+vMDX4bofw1eC9ttbOl2xo1fUh10Wl3iTKSbxOlTRkMevNULn+R wgIj2oBdbGikbDPVA0nmKI/OyPj+12//GVRJUXUPHnYXzg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-lf1-f48.google.com) smtp.remote-ip=209.85.167.48; dkim=pass header.d=brasslantern-com.20230601.gappssmtp.com header.s=20230601 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1710025145; bh=6Ah6L5lmrnHI93Emf18Td7DDrM5ijZZgxjzQ1RmCwAQ=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:To:Subject:Message-ID: Date:From:In-Reply-To:References:MIME-Version:DKIM-Signature:DKIM-Signature; b=eeRbXCdjIpO36++On4pgJLsX5nMqPrNrIsZGZwEqDbFT3F7+Y3bXdbImFR9RvMvGONfVQnBXh9 8cAyvNX2NwqnguL4UqYHW7bBpN9PcVRSQVPb5i87ySWrHLfgxRuW5De+1FI4O+ISAAIJ4qlPzr 5Gl9Oa8Bwbz5Z/aMroxW5zn3iVYuJ/Q2ff9MCUDrWT5M8Ux2mUPhIqscTSiZtzVJjOSit2VrCr +PyREHkf8sdfj5OK64mwuetJ75auC+GvHgFlVv8qVwdHgYp0DrPBzyODYJSgCd0ktlcb5WNCXl ssQS6rxQh7nHtZSuInitCV0YbzYhGBxeTKJnPMnyuhfBig==; 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:Content-Transfer-Encoding: Content-Type:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Reply-To:Cc:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=2S+3pXnulJEk+BZQOd9vMb8W4b2tAYGJFfGf9YUVOnU=; b=HT96zLycfem/iUnYCZIEHdtZna 8mUb9bXRQwN7bRxSJFZpm0CB3QOwf/Jtxk3EcrxQF0J4fN+SPopxF4+RGV/t1k6/1clKYF3FLuvMJ B+fVnhXPr5v/TTS//BwQmLQqlaLKqmuxQ+ycWEGI7KLko41HHgeVSXpV+mjaO067y1qVU7ChL7ewd AbQ3yqOrQ3dtTorr7KckQmoHtJ59aaivjggstMvCVTGkbtdHoQT6VyOHhmX1N2+iaxgVlGokKAf5v 8DyFletP4u9oJQvFdpTsD9cusHSXVJn4a6gJzwfbs1zK0jX5Xi0OF7NfYLfjXfcUDflEZk3kQerii uBgDm2xA==; Received: by zero.zsh.org with local id 1rj5ej-000LeT-HN; Sat, 09 Mar 2024 22:59:05 +0000 Authentication-Results: zsh.org; iprev=pass (mail-lf1-f48.google.com) smtp.remote-ip=209.85.167.48; dkim=pass header.d=brasslantern-com.20230601.gappssmtp.com header.s=20230601 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-lf1-f48.google.com ([209.85.167.48]:50376) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1rj5e2-000KwC-K0; Sat, 09 Mar 2024 22:58:23 +0000 Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-5135486cfccso2499176e87.0 for ; Sat, 09 Mar 2024 14:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20230601.gappssmtp.com; s=20230601; t=1710025102; x=1710629902; darn=zsh.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2S+3pXnulJEk+BZQOd9vMb8W4b2tAYGJFfGf9YUVOnU=; b=QcScUvrzI/n8ReKdodHSaFu9tgUHFfa5LqbMpGq1dUM/mCYNCmn1sYLrPBoKixNFM7 gHwTXAnGcnyE95UEMbQCWbMZAcF7NfkBSMh979GUNJAgQ2gp6Ny6frH8kQo+Mqxu/bk1 4Ezi7LIxYDakDSmThDaUUJPU27SX4suS4lcDqXKyPfB8l40Iwd1XYKH1FvqdY8tNAs3u LtYH5kAKaKdlexGrK3eidMem8UY9/rEGPOO5BdDNnHIo0MKeJh9gPsjSuO8+hK7m3VNT kbNfaXP0YGxyHGcdgQ23xJo4u4+w3zsoYz25T8gbhoWiNBG/RQHLEnAtc0LvyDNPirK3 Cy8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710025102; x=1710629902; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2S+3pXnulJEk+BZQOd9vMb8W4b2tAYGJFfGf9YUVOnU=; b=d77ovkb04oHHE4+2j8uJvM/f5XsF6+MBxJyr8/7x6L5yKyjgD5cFgkFOAzm6VlTpDd dUJKlAoEpdfEerAryPtRMU18Yc1/ZBJ27WG2XEVQAbyvppD+od0+xUlivMHfFc+HIq3r ydL1K3YQYwyTbS3lzBFNSeJu2rY9x+IyTM3pFzMZTFHTW0Txy/iO2Vjo7S4MjXmzrDSo xMhXPfw3EaUyVkIydIHDc4k0utrP7LOmioqcxU8e0TH6j8XGcP9c3LcNgwQ6iKilhzSi LP97WrzbOlt0WLUL29EyorvcF1JPDs6TrRPIMIalrzhPC1GsR6s7r7/DL6dh59X8dZCL PI4w== X-Gm-Message-State: AOJu0Yw/bGj6Cpudnaykc4fF7mdsu6ukzxYJIgLaqqWZ7t74hun9uvri +S94a8UDoPA9QZfllkHKmAGdE4xuxI+KhVI3dxozyYTWphdwmdxHjOp6TwVbrnu10BTugIPyHNU iUOeyTqXWw1AewXxcC1P1UCK9F5PTXjhv1kX42LsNPF5ZYp8= X-Google-Smtp-Source: AGHT+IGhXY8jd2BnGi5C7hN85FXEpy3maiFuE12ZbSG0vD9AXzPN0Fb+D/KKfGuUcEKtwcrAV6emRhaNOq5QvFOT46c= X-Received: by 2002:a05:6512:3442:b0:513:17ea:e490 with SMTP id j2-20020a056512344200b0051317eae490mr1672013lfr.61.1710025101600; Sat, 09 Mar 2024 14:58:21 -0800 (PST) MIME-Version: 1.0 References: <20240309143036.xwqm234mtu5wqh2r@chazelas.org> In-Reply-To: <20240309143036.xwqm234mtu5wqh2r@chazelas.org> From: Bart Schaefer Date: Sat, 9 Mar 2024 14:58:10 -0800 Message-ID: Subject: Re: Why would I use .namespace.myvar? To: Zsh Users List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Seq: 29723 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: On Sat, Mar 9, 2024 at 6:30=E2=80=AFAM Stephane Chazelas 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=3D1 b=3D2 c=3D3; }; 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, $=CB=90mynamespace=CB=90myvar or $=F0=90=85=82myname= space=F0=90=85=82myvar [...] > 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".