Menu ▾ ▴

#72 Refine Property Management

open
Jon S. Berndt
Architecture (30)
7
2012-10-31
2010-08-17
Jon S. Berndt
No

Refine property management so that errors are caught, but flexibility is supported. The property managemnet enhancements should:

1) Catch the use of properties that are undefined.
2) Permit the use of properties anywhere, when they have been properly defined elsewhere
3) Catch the multiple definition of properties with the same name

Discussion

  • Dennis Linse

    Dennis Linse - 2010-08-17

    But isn't (3) what you do with autopilot gains using the so-called "interface properties"?

    And clearly (1) and (2) are going to take a multi-pass system, first allowing anything to be used, and then looking back over the tree to see what is defined appropriately. But you knew that...

     

  • Nobody/Anonymous

    Nobody/Anonymous - 2010-09-05

    I think this is an important step, as is also being demonstrated by bug reports showing how deficiencies in current property management may even cause FlightGear to crash: http://flightgear.org/forums/viewtopic.php?f=18&t=8483

    But this effort should really be coordinated with the simgear project, to ensure that the changes suggested and introduced are also supported, and can also be used by other "users" of the property tree code (such as fgfs).

    Especially, because there are a number of proposals in place to improve the property tree code in various different ways, some of which have even been documented in the FlightGear wiki: http://wiki.flightgear.org/index.php/Recommended_Property_Tree_Enhancements

    To any sane software developer, it would seem highly desirable to maintain the utmost possible degree of compatibility between all programs and places that make use of the property tree code to ensure a maximum degree of interoperability.

    Particularly, because the property tree is such a central piece of the whole FlightGear design.
    Developing or even maintaining multiple different versions or branches of the property code in parallel is most certainly not desirable or even feasible in the first place.

    The introduction of so called "vector properties" ( http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21558.html ) was a very unfortunate step for the FlightGear project as a whole, and would have most certainly been frowned upon by the original designer of the property tree, because it is so clearly out of line with the rest of the whole design.

    The mere fact that the objections voiced by a number of FlightGear key contributors and a major FlightGear core developer like Melchior Franz (who has had a most impressive track record of FlightGear contributions and CVS commits in a long time) were ignored, is just plain disrespectful, shameful and unprecedented in the whole FlightGear project history. This mistake should not be made again.

     

Log in to post a comment.