If the data is best represented that way, why not?
When you have a data structure that is by itself simpler, but doesn't represent your data very well, things can become more complicated than if you just the best fitting data structure in the first place - even if it's deeply nested. | [reply] |
He is solving one problem by trying to directly accessing the data, and then causing another problem because he has to deal with autovivification.
The code becomes larger and harder to understand. I am also willing to bet that this sort of 'check' would be used in more than one place in his program. It should be abstracted out as method and named so that it makes senses in the context that it is being used.
Another reason to avoid directly accessing deeply nested hashes is when you need to change the data structure. If you are accessing values directly, you end up changing a lot of code to use the new data structure. If it is hidden behind a method, then you only need to change the method to fix the program as a whole.
| [reply] |
You don't have to bet on something clearly stated. Everyone else who read my motivation in OP won't bet against you :-)
Anyway, accessing deeply nested data is not the problem, neither is avoiding autovivification. I designed the data structure the way it was. I learn from the experience that structuring my database right would make me programming better.
But I see some point in your statement, and I agree with that. That's why I put the code accessing the data directly in a method (somefunc() in my example). And I have other methods doing this, accessing different branch from the same tree. They all check carefully to avoid autovivification to avoid larger problem for the next check.
Only those methods (in one class) need to access the data directly so client modules don't need to know the detail. The latter accomplish their tasks based on higher abstraction.
Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!
| [reply]
[d/l] |