Recommended Property Tree Enhancements: Difference between revisions

m
Line 18: Line 18:
In addition, such losely structured and organized write access to properties also raises the question of housekeeping and cleanup responsibility, once data needs to be cleaned up for example, i.e. when re-initializing a specific subsystem or possibly the whole simulator.
In addition, such losely structured and organized write access to properties also raises the question of housekeeping and cleanup responsibility, once data needs to be cleaned up for example, i.e. when re-initializing a specific subsystem or possibly the whole simulator.


As of 05/2009 this is an issue that has also been discussed on the jsbsim developers mailing list, because there is currently no clear policy whether distinct components (such as an FDM) should generally only mutate internal/private state (i.e. state that is at least conceptually 'owned' by the component) or whether components should also mutate outside state outside their branch of the private property tree (see [[FDM_engine_feature_standardization#Constraining_Property_Tree_Access|Constraining Property Tree Access for FDMs]] for details).
As of 05/2009 this is an issue that has also been discussed on the jsbsim developers mailing list, because there is currently no clear policy whether distinct components (such as an FDM) should generally only mutate internal/private state (i.e. state that is at least conceptually 'owned' by the component) or whether components should also be allowed to mutate outside state outside their own branch of the private property tree (see [[FDM_engine_feature_standardization#Constraining_Property_Tree_Access|Constraining Property Tree Access for FDMs]] for details).


=== No concept of (exclusive) property ownership ===
=== No concept of (exclusive) property ownership ===
2,561

edits