John Wojnaroski writes: > > Fundamentally, this is a design optimization: it makes the very > > common cases of accepting configuration from the user and > > exporting state to the panel XML much easier to maintain over > > time. These cases are hurt, instead of helped, by having a firm > > C++ interface for everything. > > Are we sub-optimizing to a point design for convience? Okay some > things get better, but it sounds like this will "bypass" some of > the basic ideas behind C++. Heck, let's go back to fortran and put > everything in COMMON. Sorry, I don't see the panel as the primary > feature of flightgear, so why should it drive the design. IMHO EOMs > and scenery generation are the biggies not to mention real time.
Think of what we're doing as analogous to a wordprocessor, a spreadsheet, or an image editor: we're separating the contents (document, tabular data, or graphic) from the programming interface. Of course we need a lot of good, C++ interfaces, and with time we'll try to improve what we have; however, it makes no more sense to hard-code an FDM's properties in a C++ interface for a flight simulator than it does to hard-code column names in a C++ interface for a spreadsheet. > NO, poor design is not inevitable. Perhaps it is a consequence of > trying to be all things to all people. It's a matter of managed evolution and resource availability. C++ coders are in short supply, C++ coders who understand and use modern design patterns are in even shorter supply, and C++ coders who meet the previous criteria *and* have managed to understand the FlightGear codebase are very rare indeed. It makes sense to shift the effort to where more resources are available. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
