Thank you very much for this detailed description. I'm really glad that I
never had a computer science professor, worrying too much is not very
healthy. :-)
Regards
Alexander
On Thu, 4 Apr 2002, Curtis L. Olson wrote:
> Alexander Kappes writes:
> > Hi David,
> >
> > > Just about any information you want is available in the property
> > > tree. There's an interactive GUI browser built into FlightGear --
> > > choose "Properties" from the "View" drop-down menu.
> >
> > How do I have to imagine this property tree, I mean how is it realized in
> > memory (C++) and what kind of things are stored in it? Is it something
> > like an interface between different parts of FGFS?
>
> Another way to look at the property manager is as a 'key/value' hash.
> Any part of the program can lookup a property name (key) and it's
> associated value. Values can be of type integer, boolean, float,
> double, and string.
>
> For convenience the property names (keys) are arranged in a way that
> appears like a hierarchical tree structure. You can traverse the
> property 'tree' in much the same way as you would traverse the
> directories in a file system.
>
> The relative merits of this approach have been discussed at great
> length and with great vigor on this list in the past so I'd rather not
> replay that again now, but let me summarize.
>
> The upside of this approach is it is *very* convenient and flexible.
> When you begin dealing with things like aircraft with vastly different
> types of control inputs, flight model codes with vastly different
> types of data outputs/inputs, instruments and instrument panels that
> care about vastly different sets of parameters, the traditional
> computer science taught approach to building interfaces (at best)
> becomes extremely cumbersum and (at worst) starts to completely break
> down.
>
> The downside of this is that now we have tossed out several key
> principles drilled into our heads starting at day one by our computer
> science professors. We now have things like 'global' shared state
> that can change anywhere in the code. (Bye bye abstract data types.)
> Properties aren't variables so they can't be type checked or even
> 'spell' checked by the compiler. And people have brought up
> performance concerns incurred by the extra layers of indirection.
>
> However, from a practical standpoint, we need *some* global state.
> Much of this computer science theory works wonderfully in simple demo
> programs, but doesn't always scale well to the practical needs of
> large complex software projects. Profiling has shown us that at least
> at this point, the performance of the property manager isn't a
> problem. We have been bit on occasion by 'spelling' errors that the
> compiler can no longer flag for us, but those have been pretty
> straight forward to track down and fix.
>
> There are some definite trade off's that can be intelligently argued
> either way.
>
> So the conclusion here is that 'practice' seems to have won the battle
> over 'theory'. And all those evil things we were told would happen to
> us if we disobeyed our computer science professors ... well as long as
> we know and understand the dangers, we seem to have been able to
> minimize, manage, and containt the problems. Life isn't so bad this
> way and the project hasn't imploded upon itself. The longer we run
> with the property manager without encountering a violent end to the
> world, the more confidence we have in our approach. :-)
>
> Regards,
>
> Curt.
> --
> Curtis Olson IVLab / HumanFIRST Program FlightGear Project
> Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED]
> Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
>
> _______________________________________________
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
