Topic: Reformatting borealis_formats.py and base_format.py to reduce the redundancy between different file types of the same version.
Description
The current implementation of borealis formats shares a lot of data fields between the different types of Borealis file (antennas_iq, bfiq, rawacf). All of these shared data fields are expected to have the same type. This ends up being a lot of boilerplate copy-paste code.
I propose that it would make more sense to define the type of each data field once per version, rather than once per file type per version. We would still probably need a class for each file type, but these classes could all share the list of data fields and types rather than redefining them. This would make it easier to define a new data format as Borealis file types evolve, as you would only need to update the list in one spot as opposed to 4.
The big offenders here in terms of copy-paste code are single_element_types() and array_dtypes() methods for each version.
Discussion
Topic: Reformatting borealis_formats.py and base_format.py to reduce the redundancy between different file types of the same version.
Description
The current implementation of borealis formats shares a lot of data fields between the different types of Borealis file (antennas_iq, bfiq, rawacf). All of these shared data fields are expected to have the same type. This ends up being a lot of boilerplate copy-paste code.
I propose that it would make more sense to define the type of each data field once per version, rather than once per file type per version. We would still probably need a class for each file type, but these classes could all share the list of data fields and types rather than redefining them. This would make it easier to define a new data format as Borealis file types evolve, as you would only need to update the list in one spot as opposed to 4.
The big offenders here in terms of copy-paste code are
single_element_types()andarray_dtypes()methods for each version.Category