Melchior FRANZ wrote:
> 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!)
I'll get my flaming out of the way first off. I'm very disappointed that
you launched the discussion in this way. I explained to you in private
email why it was inconvenient for me to write an RFC right at this time,
promised not to check any major changes to the property system in until
there had been a discussion and favorable consensus, and pushed my code
to a public Git repo for you to examine. Now there are 18 emails on the
list responding to your channeling of... a mixture of our IRC discussions
and the code, I guess.
I am only proposing to add Vec3d and Vec4d properties, not COLOR or POSITION
or whatever. However, I wouldn't be opposed to other multi-value types such
as Matrix4x4.
> 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;
> };
>
Actually, in C++ it's often accessed using array accessor syntax, like
color[0], or you refer to the whole color as "color".
> 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.
I agree with the importance of the property system, but automatic
conversion is mostly a crock. What's the boolean value of .01? Of
.000000001? Of -.000000001? Actual types matter, even if there are
default conversions.
>
> 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?
The RFC describes how these vector types are written: with spaces between
the values. Maybe I'm showing my naivete, but who's writing parsers that
isn't using libsgprops?
But this last objection, and many that follow, assume that, wholesale,
properties up and down the property tree will be changed to use this
new feature. I'm not proposing that. If the vector properties are so
viral, perhaps that's a good problem to have.
>
> 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?
Can you point me to an example of this? Otherwise I'd say "write some
Nasal."
>
> 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?
It's well defined; basically 0 is the result. But I can't believe that
writing a bool to the "red" child of a color gives you a sensible result,
even though it's defined to be the value "1". If you're writing a bool
to a color component, shouldn't you fix your buggy code?
>
> 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?
Is this serious?
>
> 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?
>
If there start to be interesting properties that are vectors, then yes.
Or the input field could accept 3 numbers separated by spaces. However,
if such an application is tied so closely to a specific data representation,
then it is already living on borrowed time.
> 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?
As I've said before, it's <foo type="vec3d">123 341 123</foo>. Yes,
if an application isn't using libsgprops and wants to parse such a
property, it would need the 5 lines of C++ code to do that.
>
> 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!
It's not going to work that way.
> 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.
I just don't see it that way. I have a specific set of new properties
in mind as the target for this feature.
Tim
------------------------------------------------------------------------------
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
