improve the approach we use for parsing and storing component data

[superwhiskers]

this pull request replaces the data structures for components introduced in #133, save for those related to buses. this is done to simplify the way json parsing is handled for them

checklist

• All tests pass.
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit™ style guidelines.
• There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.

[pelesh]

Class BusFault.cpp includes (indirectly) both, nlohmann/json.hpp and magic_enum/magic_enum.hpp headers. This makes the component dependent on I/O file parser implementation. We need to find a way to abstract away component models from the parser specifics. All component models should build independently of the parser (where it is okay if the parser depends on components).

[superwhiskers]

i'm not sure it's really possible to decouple it any further unless we added even more intermediary structures or something. both of those headers could be removed and with some conditional compilation, since all of the actual json parsing code resides in the one file, it'd be easy to remove the json parser and magic_enum. i don't think attempting to completely remove an indirect dependency is particularly worthwhile here.

[superwhiskers]

well, actually now that i recall there's one field in the ComponentData.hpp file that needs magic_enum. the json parser, however, can be removed completely. it technically doesn't even have to be in that same file (but i put it in there because it simplifies things for the user as they wouldn't have to include a separate "json parser" file to use the json parser with components) as the json parser we use only requires things to be 1) in the same namespace¹ and 2) included within the file they are being used within

Footnotes

1. technically it's not required but it makes things simpler ↩

[pelesh]

Also parser tests should not be in phasor dynamics but in a separate subdirectory. They are helper utility, not the part of phasor dynamics core.

[pelesh]

i'm not sure it's really possible to decouple it any further unless we added even more intermediary structures or something.

Then I guess we should add intermediary data structures, i.e. meta models. Also, we should consider using factories to instantiate and parametrize components.

[superwhiskers]

Then I guess we should add intermediary data structures, i.e. meta models

we already have an intermediary (the *Data family of structures). i'm concerned adding even more would overcomplicate the entire set of classes and data structures we have and for little tangible benefit. i already think what we're doing here is a little much, but i can see the benefit (decoupling our internal representation from the exposed one). adding even more seems unnecessary and would duplicate representations all over the place.

we can already remove the json parser from the ComponentData structure easily and i don't see the benefit of going any further than that as the data structure itself has no reliance upon the existence of it and it's served its purpose (making individual *Data structures not need to deal with json parsing and simplifying the process of adding new components).

adding even more structures would be detrimental to your original goal, i think. it would require consumers of the library to interact with more structures to get things done (unless i'm interpreting the proposal wrong) and again, duplicate places in which data can be and incur a greater maintenance burden upon us. without more justification and a clearer path to implementation i'm against making this change, personally.

[superwhiskers]

this should be ready to go now

[superwhiskers]

rebased on latest develop and made changes to fix the new ThreeBusClassical test

[pelesh]

Just a couple of nitpicking comments.