double usage of predict_orbit about libpredict HOT 3 CLOSED

We have kind of been following https://www.kernel.org/doc/Documentation/CodingStyle, Chapter 5: Typedefs on this, but probably not very consistently.

History:

struct predict_observation never had the _t-ending in order to elucidate that it was a pure output struct where all elements could/should be freely accessed, and didn't need no create function. So in solving issue #22, I also changed predict_orbit_t to struct predict_orbit in order to make it be consistent with struct predict_observation. I considered that it might cause some trouble with predict_orbit(...), but couldn't see any errors or warnings or find any indications of this on the Internet, so I thought it was fine. O:-)

Possible solutions:

1. Rename struct predict_orbit and struct predict_observation to predict_orbit_t and predict_observation_t.
2. Rename struct predict_orbit to something else (difficult to find a better name).
3. Rename predict_orbit(...) to something else (predict_calculate_orbit?)
4. Add a typedef of struct predict_orbit for the python bindings.

Personally, I think it is nice to use struct name instead of name_t for the output structs in order to have clear separation between those and the structs that need initialization through a ..._create_... function.

@ryeng, what do you think? o:-) Even if C handles struct predict_orbit and predict_orbit(...) fine, I guess it is a bit confusing to have the same name in the API anyway.

from libpredict.

Rename to struct predict_satellite? struct predict_orbiter?

from libpredict.

After an oral discussion, we decided to go for struct predict_position, as it sums up what we wanted to convey with predict_orbit.

TODO:

• Replace in all source files, header files
• Replace in examples
• Replace tests
• Replace in README.md

from libpredict.