Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: ${(kv)foo[bar]}
- X-seq: zsh-workers 21091
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: ${(kv)foo[bar]}
- Date: Sun, 03 Apr 2005 19:58:51 +0000
- In-reply-to: <200504032200.41605.arvidjaar@xxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <200504031435.19457.arvidjaar@xxxxxxxxxx> <1050403174903.ZM4196@xxxxxxxxxxxxxxxxxxxxxxx> <200504032200.41605.arvidjaar@xxxxxxxxxx>
On Apr 3, 10:00pm, Andrey Borzenkov wrote:
} Subject: Re: ${(kv)foo[bar]}
}
} Although it is rather hard to understand why ${(kv)opt_args[(i)--media]}
} should work and ${(kv)opt_args[--media]} not.
The rationalization is that with [(i)...] the subscript is a pattern, so
you may not know in advance what it's going to match, and therefore it
is useful to be able to return both the key and the value. [(i)--media]
is a degenerate case where the pattern is a plain string. Without the
(i), the subscript is always a plain string and therefore known, and you
don't need to be able to expand it.
The real reason, as I said, is that the implementation of subscripting
with [(i)...] does a scan of the hash keys rather than a simple hash
lookup; it's got code that's shared with (R) and (I) and therefore is
designed to return an array. Implementing subscripting with a full
scan in the ordinary case just for (kv) would foil the reason for using
a hash table to begin with.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author