This will probably become a flame-war, but I see no way to avoid
it. Tim plans to extend the property system with compound data
types, such as VEC3, VEC4, or COLOR. We've discussed this three times
in IRC, and I've always pointed out why this is IMHO a *BAD* thing,
and why I strongly object. But now he has implemented it in his
source, and made that the base of further (desirable!) features.
I don't want a flame war with Tim, but this needs to be decided
*now*. Otherwise we might end up having to decide whether we want
the (IMHO) "evil" property change *and* the nice features, or
neither. And that's not how a decision about one of our foundations
should be made!
(To Tim's defense, he had planned to write an RFC to the devel list
about it, though he also intended to commit parts of the change before
that. And to my defense: I have told him that if he doesn't write the
RFC *soon*, then I will bring it up on the list!)
What is it about: Currently, if we have data in the tree that belong
together, this is done via subnodes under a common property, e.g.:
color/
|__red (float)
|__green (float)
|__blue (float)
just like it's done in C or C++:
struct color {
float red;
float green;
float blue;
};
That is: each component is a basic standad type and can be accessed
as such, but the whole structure can be passed as one, too. The
property system contains the standard types from C++: BOOL, INT, LONG,
FLOAT, DOUBLE, STRING (= char*), as well as UNSPECIFIED and NONE.
Subsystems publish values in these basic types and access data from
other subsystems. This is done from within C and C++, from Nasal,
via property browser, property display (on screen), and remote
access is possible via telnet/socket, http, protocols, or properties
are just loaded from XML files directly into the tree.
All data types can be read as any other datatype (except the special
ones UNSPECIFIED and NONE), in which case the data are converted
appropriately and as one would expect. It's possible to read a BOOL
into a double, and to write a double to a LONG. The property system
is one of the foundations of FlightGear and has worked very well for
a long time.
Tim's planned patch will IMHO degrade the system and remove essential
properties. How should such a VEC3 property be displayed in the
property browser? In one line, separated by semicolons? Will everyone
who reads the data have to write parsers for the compound type?
How will one attach a GUI slider to the red property, if it doesn't
have its own property path, but is thrown together with other
properties?
What happens if I write a bool value to a VEC3 property? Will it set
all three values to 0 or 1, or only the first? Or will it return an
error? What will I get if I call getIntValue() on a VEC3 property?
What happens when I read out a color via telnet? Will I get
"0.123;0.5;0.6667"? Will people have to learn that the first of
them is red, the second blue, and the third green?
Will input fields in remote applications (instructor) have to write
special validators for VEC3 properties, rather than just having
three fields that accept a number?
How will a VEC3 property be written in an XML file? As
<foo type="vec3">123;341;123</foo>? Will then every application
which reads such a file have to have its own (sub)parser for
certain fields, in addition to using an XML parser?
Or will the compound properties no longer be public at all, but be
kept secret, with no way for the user to inspect and change them?
Or will the whole throwing-together of properties only happen
internally, while they are still presented as separate data
types to the world? But what's the whole point of it, then?
We already have that, as separate properties can already be
loaded into an SGVec class!
In my opinion this planned change would be an incredibly bad
move, and would almost have to be seen as the destruction of
the property system. So let me repeat: I strongly object.
Please no knee-jerk reactions about whether I am in the position
to "strongly object" or not, no discussions about whether Tim is
an important project member and core developer who has contributed
significant improvements and features to fgfs -- of course he is
and has, and no discussions about whether we want effects, shadows,
and landing lights -- of course we do. This is about the property
system and compound property types.
m.
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
