Re: Nested associations (was Re: PATCH: completion functions)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> On Aug 26, 11:28am, Sven Wischnowsky wrote:
> } Subject: PATCH: completion functions
> }
> } [If] we were able to put arrays and associations into associations, we
> } could have command-specific caches. Internally, this probably wouldn't
> } be too hard to implement, I think, but if I remember correctly, Bart
> } was against it and explicitly disallowed this. Maybe if we just tell
> } the users that associative arrays can act as name-spaces? (In other
> } words: Bart, what was the reason that you was against it? Or weren't
> } you against it and my memory is failing?)
> 
> I wasn't against it; in fact I particularly arranged the storage for
> associative arrays to allow for it to be added in the future.  There are
> a number of reasons why I didn't do more with it:
> 
> I thought it would be better to have it thoroughly tested and working
> one level deep before allowing nesting.
> 
> I think we need better assignment syntax before allowing nesting; how
> do you copy one nested AA to another?
> 
> Similarly, I can't decide how expansion should behave.  What happens when
> you refer to the entire tree structure with $outermostname ?  What about
> ${(kv)outermostname}; do the flags propagate to the nested arrays?  Why?
> When you ask for $outermostname[(r)...], how is the pattern compared to
> nested sub-arrays?  And so on.

Ok, I didn't think about some of these, sorry. (Now I have some things 
to think about...)

> Internally, the code is not well-organized to re-enter parameter table
> lookups during processing of multiple subscripts.  As with much of zsh,
> the parameter lookup code depends on a global value, which I hacked to be
> saved/altered/restored during associative array operations.  By the time
> you're past the first level of subscripting, it's unclear (to me, anyway)
> whether you still have all the necessary data to swap into the `paramtab'
> global for the next level of lookup.
> 
> Finally, you can get much the same effect either by careful choice of key
> names or by indirection with ${(P)...}, so it didn't seem to be necessary.
> 
> Why can't you do e.g. _args_cache_dopts[$command.$tmp]="${1#*:}" where
> $command comes e.g. from passing the name of the current command to the
> call to _arguments from the other completion functions?

Because some of them are arrays or assocs. On the expansion side we
could use `${(P)...}', of course (and I'm tempted to implement that),
but since we changed the code to disallow expansions on the left hand
side of assignments we would have to use lots of `eval's there -- and
I was just too lazy to write that (and I don't like it, I liked
being able to do `$foo=...').

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx