ilyash-b
commented
2 years ago The idea here is to be able to automatically build deeply nested data structures made of Arr and Hash for intermediate nodes.
Sounds fine. In my opinion it should not be the default behavior as it can hide errors when you try to access something that you think should exist.
The way I see it is that autovivification may be seen as a generalization
I understand why but from my perspective it's very hard to see it the same way because right now it's special syntax E1.field_name = E2 and E1[E2] = E3.
Background
- I am very reluctant to add new syntax in general. Let's put
{key}aside for now?
Design alternative 1 for discussion:
z.a[7]{A}{B}{C}[8]{mykey}="Hello World"would be
z.deep_set(7, 'A', 'B', 'C', 8, 'mykey', "Hello World")what I like about this solution is it does not involve any new syntax and should be relatively easy to implement. Up for discussion:
- The whole idea of having this facility as a function/method
- The name
deep_set - Parameters - maybe more idiomatic (but less convenient?)
z.deep_set([7, 'A', 'B', 'C', 8, 'mykey'], "Hello World") - Return value:
zor"Hello World"(zwould be more idiomatic)
@rdje, let us know what you think
rdje
The idea here is to be able to automatically build deeply nested data structures made of Arr and Hash for intermediate nodes. The leaves could be anything of course (Any).
Assuming z is a variable, writing
would automatically create all the intermediate Arres and Hashes until reaching the final Hash with 'mykey' as key to store the "Hello World" Str.
Note that in the above example I am assuming that the things inside {...} are stringified.
No matter how it is actually done, the idea is to provide a way to create deeply nested data structures based on a few well known types (Arr and Hash here) by simply referencing the leaves starting from the top level variable and letting NGS figure out (DWIM) what the intermediates are (Arr, Hash or something else) and initializing them as appropriate.
I used autovivification systemacally when parsing files and storing the extracted information in a structured way using deeply nested data structure (DNDT) made of Perl5 lists and hashes without worrying about predefining and initializing all the intermediate nodes (list / hash).
I just relied on Perl5 to DWIM to help me with constructing my model view dynamically.
People will find their own use cases but the bottom line is to write things as if the referenced terminal leaves were already present, NGS would then fill the gap (DWIM) and build the route or path to reach those final or terminal leaves.
The way I see it is that autovivification may be seen as a generalization of the exemple you gave me when I asked in a previous post about how to define data/variable member of a type MyType, you answered by writing
Here 'anything' may literally be anything, from a simple identifier to an Arr element reference to a Hash element reference or even to a full-fledged autovivified path to a leaf node value.