It seems someone already gave you write access to orekit-tutorials before me. Could you
check if it works?
My bad, it seems like this was a git configuration issue on my side. Iāve now been able to push the new develop branch to the tutorials repos, so my commit rights work. Iāll push the commit for the typos later today. Sorry to have bothered you for nothing.
I can merge them all into the develop branch.
Nice tutorial! The code, good for a tutorial, would create performance issues if used in production. Every time context.getFrames() is called it creates a new set of frames. Would be a memory hog and could hurt performance since the equality shortcut in frame.getTransform(...) would not be used. I created CompositeDataContext to have a convenient way to address this issue. Again, not an issue for a tutorial, but I would be nervous if someone pasted that into production code.
Also the loop output should be indented show it is treated as preformatted.
Thanks for writing the tutorial!
I fixed this on the new develop branch of the tutorials repo, along with a couple other typos.
I did not touch the tutorial code however, so your other points are still applicable.
Hi,
I would like to make a further proposal regarding data contexts.
In this same thread, solutions based on ThreadLocal and implicit contexts were discussed and eventually rejected, mainly because explicit objects were preferred and implicit behavior was considered hard to manage and reason about.
However, I believe there is room for a slightly different approach, not aiming to replace the explicit DataContext design, but to optionally extend it for specific application-level use cases.
The main idea would be to introduce activable implicit contexts, resolved at runtime through a dedicated DataContextResolver. By default, the feature is disabled; in this case, Orekit would behave exactly as it does today, relying on the default data context with no implicit behavior.
When explicitly enabled by the user, the resolver could dynamically select the appropriate DataContext (using a ThreadLocal, for instance), allowing existing code to run unchanged.
The main intent is to cover all the use cases where the use of explicit objects would be difficult/impossible (e.g. support large or legacy applications where adapting all call sites to explicit contexts is impractical) while still keeping the responsibility and the risks at application level.
While I agree that such a mechanism would not be suitable as the default behavior of the library, I believe that making it an optional extension/a controlled mechanism would only increase the number of use cases covered, without affecting the main design of Orekit.
I would be very interested in your feedback about this āconstrainedā variant. Would it be doable in your opinion?
Hi sputils6,
Are you able to create the classes you propose in your own code base and use them? I wondering if there is any need, or advantage to having them in Orekitās code.
As you mention, TreadLocal is specifically designed for passing parameters around legacy code that canāt be modified. (See e.g. Josh Blochās āEffective Javaā.) So it might make sense to use ThreadLocal in your case with your legacy code, but Iām not convinced that making a complex part of Orekit even more complex is the right solution.
As youāve noticed, mutable static variables make it very hard for the user to control the behavior of the application. IMO the solution is to remove the use of mutable statics instead of making the mutable statics more complex.
Adapting large applications to pass an explicit context does take effort, but is not impractical. Consider the case of Orekit itself, which is large and was updated to support passing an explicit data context. Donāt forget there are tools to help you: the dataContextPlugin for the compiler, and the ExceptionalDataContext for your unit tests.
Regards,
Evan