Re: assoc array memory mucking, and semantics of patterned keys

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> 
> "Bart Schaefer" wrote:
> > The final possibility is to change the meanings of (r) and (i) when an
> > AA is involved, so that (r) means search the values and (i) means search
> > the keys.
> 
> Without thinking too hard, because I want to get some work done today,
> I think I prefer this, because the (k) and (v) flags always refer to
> what's returned, while the (r) and (i) flags always refer to what's
> being searched.  It's both neat and powerful.  It's maybe annoying
> it's different from normal arrays, but I think understandably so.
> Once you've got the point that (i) tells you to search the index, not
> return it, it's entirely logical.  Otherwise the meanings of (k) and
> (i) are mixed in a slightly messy way.

Agreed. Also, I would like to have ${(k)param[(r)pat]} on normal
arrays work like $param[(i)pat] (as Bart suggested in his list). I
probably would even want ${(kv)param[(i)pat]} (and the same with (r))
give a list of indixes and values for normal arrays, just to make
things more consistent.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx