From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3665 invoked by alias); 2 Nov 2015 15:43:55 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20874 Received: (qmail 17708 invoked from network); 2 Nov 2015 15:43:52 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Authority-Analysis: v=2.1 cv=X+5rdgje c=1 sm=1 tr=0 a=hFxs0f5JAArYXmzDxhrHQA==:117 a=hFxs0f5JAArYXmzDxhrHQA==:17 a=N659UExz7-8A:10 a=rZfRFxm3pkGPeJmp5fcA:9 a=pILNOxqGKmIA:10 Message-id: <563784B5.3040901@eastlink.ca> Date: Mon, 02 Nov 2015 07:43:49 -0800 From: Ray Andrews User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-version: 1.0 To: zsh-users@zsh.org Subject: Re: easy calling of associative array? References: <56369C7B.2030604@eastlink.ca> <1237641446422150@web6m.yandex.ru> <5636B333.8060300@eastlink.ca> <151101190842.ZM16752@torch.brasslantern.com> <5636D99F.2030807@eastlink.ca> <151101225100.ZM16882@torch.brasslantern.com> In-reply-to: <151101225100.ZM16882@torch.brasslantern.com> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit On 11/01/2015 10:51 PM, Bart Schaefer wrote: > Anyway, that's actually the point. ${(P)ref} resolves to the values of > the array, and then the subscript is applied. Ask yourself: what are > "the values of" an associative array, in every other context? I'll give it some time, this is new to me. It seems that with an associative array, what we have is some 'hidden' syntax, IOW there is a sort of shorthand going on. As with math, I'd sorta expect that if this functionality was tacked on after the fundamentals of the shell were already in place--you leveraged what was there--there'd be asymmetries. Experimenting with trying to make accessing associative arrays convenient: echo_v () { echo ${(P)${:-${1}[$2]}} #this works #eval "echo \$${1}[$2]" #and this works too. } get_v () { #$3=${(P)${:-${1}[$2]}} #nothing works eval "$3=\$${1}[$2]" #this works } set_v () { # {(P)${:-${1}[$2]}}=$3 #nothing works eval "${1}[$2]=$3" #this works } test_v () { #eval "${1}[$2]" #nothing works #this works [ ${(P)${:-${1}[$2]}} = $3 ] && echo 'all too true' || echo 'alas, no.' } I notice that with 'echo_v' I can use your syntax or 'eval' the thing which is much easier to read if nothing else. But with 'get_v' and 'set_v' I can only make it work with 'eval' whereas with 'test_v' I can *not* make it work with 'eval'. At the risk of being too much of a symmetry nut, is it possible to make either form work in all the above situations? If so, I have a consistent interface to these arrays which would be pleasing, but it's an academic point. FWIW, this is in the context of studying Sebastian's stuff--there's all these variables sloshing about for each of several zcurses windows, and it would be C-ish to organize them into arrays, one for each window. However I can see that this is at the limits of what a shell should be asked to do, since what I really want is a proper C structure for data: main_window.window_height becomes: ${main_window[window_height]} ... but of course I want to be able to replace 'main_window' with any other window via a variable passed to whatever function: whatever_window->window_height becomes: ${(P)${:-${whatever_window}[window_height]}} ... which looks like it's going to work just so long as I can perform any sort of operation on the array without difficulty. But there could be speed issues and the whole thing might not be worth the trouble, but it is educational at least.