Talk:Recommended Property Tree Enhancements

From FlightGear wiki
Jump to navigation Jump to search

2014

Related Discussions

I/O Properties

Property Meta Information

  • "I'd also be interested in hearing what enhancements to the property manager (such as constraints) would be useful for the property picker's future development." [1]
  • "For example, we could add some kind of simple schema support, with constraints and enumerated lists of allowed values" [2]
  • "Ranges" and "Value lists" would be good. [3]
  • "I certainly do agree that selectable units would be nice to have" [4]
  • min/max (ranges) for properties [5]
  • regarding implicit unit conversions [6]
  • This [7] shows how jsbsim requires and emulates the same functionality (constraints min/max, stepping) using a much more verbose syntax, which is however specific to jsbsim and could be easily generalized by adding this feature to the SGPropertyNode class using corresponding attributes
  • in an increasingly multi-threaded (or multi-process) environment, it would be important for properties to be "readonly" by default, so that subsystems/components would have to request/register write access to a property in order to be able to mutate it, which would also provide a way for tracking the number of registered writers to a property (branch), enabling warnings to be issued if more than one writing component is registered. Eventually, this would make dataflow much more explicit.
  • property ownership would at least need to be defined as "exclusive write access", so that all write requests would need to be proxied/channeled through the owning system, ensuring that it is aware of each attempt to modify its internal state.
  • discuss property "signals" vs. "slots"
  • providing an API to declare mutual property dependencies:"It also has an advantage that we can 'wire' the properties together.Most of the danger due to a failure is as a result of interactions and dependency-based secondary errors and additional failures. If we can say that "altimeter[0]" and "airspeed[0]" take data from "static[0]" then when the instructor sets "static[0]/blocked" the correct side effects will occur." [8]
  • not directly but conceptually related: "The cleanest solution is to have a separate property tree for each instance"[9], "Think of the property tree as the processor state,and each vehicle as a separate process."[10]
  • Similarly: "or we might just create an entirely separate property tree for each instance." [11]

Misc

Todo

  • making I/O (dataflow) explicit (see related mailing list discussion) - differentiate between input and output properties (and signals/slots)
  • tied properties and listeners don't work together too well, tied properties basically predate listener use in FG, but listener use is becoming increasingly important and standard - tied properties can thus not be used by an increasingly important API in FG
  • should print warnings, when tied properties are tried to be linked to a listener
  • there should really be an API to easily mark properties as depreciated (i.e. see Property Tree Reorganization, automatically aliasing/mirroring the new one using the depreciated symbolic name), while logging to the console that a property is depreciated, along with its new path/name.

SGPropertyNode API enhancements

Possible cleanup: There's lots of redundant code in SG & FG that basically maps the SGProperty::type enum (NONE, ALIAS, BOOl, INT, LONG, FLOAT, DOUBLE, STRING, UNSPECIFIED) to a corresponding ASCII string (and vice versa: just run a "grep case SGPropertyNode", to see how often this is really done). It would be much cleaner to simply provide two new static functions inside SGPropertyNode that do this mapping internally and return a type or a string respectively. Similarly, SGPropertyNode attributes are also often mapped manually using switch/case statements.

Also see: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26244.html

Retrieved from "https://wiki.flightgear.org/w/index.php?title=Talk:Recommended_Property_Tree_Enhancements&oldid=66306"