2,561
edits
Recommended Property Tree Enhancements: Difference between revisions
Recommended Property Tree Enhancements (view source)
Revision as of 01:02, 19 May 2009
, 19 May 2009→No access control taking place
| Line 16: | Line 16: | ||
Encapsulation is basically non-existent for many properties. This is a theoretical nightmare from an data integrity point of view, because state may be mutated from places and by components that may -strictly spoken- have no business exercising write access for certain properties or even whole subtrees of the property tree. | Encapsulation is basically non-existent for many properties. This is a theoretical nightmare from an data integrity point of view, because state may be mutated from places and by components that may -strictly spoken- have no business exercising write access for certain properties or even whole subtrees of the property tree. | ||
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 | 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). | |||
=== No concept of (exclusive) property ownership === | === No concept of (exclusive) property ownership === | ||