Thanks for providing feedback and expanding with new ideas.
I believe the summary is:
${a.key1.key2} - Static fields
${a.key1.$key2} - Mixed dynamic/static, simple substitution.
${a.key1.{complex.$key2}} - For complex keys that may contain anything
${a.key1[expr].key2] - expr is evaluated in numeric context
Did I get it right ?
Yair
On Wed, Sep 7, 2022 at 3:19 AM Martin D Kealey <mar...@kurahaupo.gen.nz>
wrote:
> Some things do indeed come down to personal preference, where there are no
> right answers. Then Chet or his successor gets to pick.
>
> Keep in mind that most or all of my suggestions are gated on not being in
> backwards-compatibility mode, and that compat mode itself would be
> lexically scoped. With that in mind, I consider that we're free to *stop*
> requiring existing antipatterns that are harmful to comprehension or
> stability.
>
> I would choose to make parsing numeric expressions happen at the same time
> as parsing whole statements, not as a secondary parser that's always
> deferred until runtime. This would improve unit testing and debugging,
> starting with bash -n being able to complain about syntax errors in
> expressions. (Yes that precludes $(( x $op y )) unless you're in compat
> mode.)
>
> On Mon, 5 Sept 2022 at 19:55, Yair Lenga <yair.le...@gmail.com> wrote:
>
>> Personally, I think adopting Javascript/Python like approach (${a.b.c} )
>> is preferred over using Perl approach ( ${a{b}{c}} ), or sticking with the
>> existing bash approach. The main reason is that it is better to have a
>> syntax similar/compatible with current/future directions, and not the past.
>>
>
> By having var['key'] and var.key as synonyms, Javascript already sets the
> precedent of allowing multiple ways to do the same thing.
>
> PPS: I'm under no illusions that it will take a LOT of work to move Bash
> this far. But we'll never get there if we keep taking steps in the opposite
> direction, piling on ever more stuff that has to be accounted for in
> "compat" mode.
>
