On Wed, Mar 20, 2024 at 3:44 PM Greg Wooledge <g...@wooledge.org> wrote:
>
> This seems rather theoretical to me. If the associative array has
> nothing in it, does it really matter whether it's nonexistent, only
> declared as a scope placeholder (I think that's a thing...), or fully
> declared but empty? The second script which receives the serialized data
> doesn't really care how the first script stored it, does it? All you
> really need is to have the keys and values replicated faithfully in the
> second script's associative array. If that gives you an empty hash,
> then that's what you use.
>
> I simply struggle to figure out what the real-world application is for
> some of these tangents.
You're right, at least for me. In my use case, the 'declare -A' bit of
the output from ${assoc[*]@A} had scope implications I hadn't
considered, and now I'm removing that bit from the argument to eval.
What I said in my prior email about actually wanting declare commands
is entirely hypothetical.
The point I'm trying to make is that ${var@A} expanding to either a
declare command, an assignment statement, or nothing, depending on
potentially changing criteria, is unnecessarily cumbersome. In
whatever circumstances where a bash programmer would actually want a
declare statement as the expansion of ${var@A}, it doesn't suit their
purposes for that expansion to not give them that under certain
conditions.
Thus why I think dedicated parameter transformations to give a declare
command or an assignment statement would be preferable. And then
another one to give the right hand side of a compound assignment
statement, i.e. ( [0]='fox' [1]='hound' ), because that's also useful.
Maybe I'm asking for too much.
