On Saturday 21 March 2009, Tim Moore wrote: > LeeE wrote: > > On Friday 20 March 2009, Tim Moore wrote: > >> RFC: Vector Types in the Property System > >> > >> Proposal: Allow vector types as properties in property list > >> XML files and as properties in the runtime property system. > > > > [snip...] > > > >> Rationale: Without these types, the XML syntax is much more > >> verbose > > > > [snip...] > > > >> Discussion: > >> The property system is very useful and I want to use it for > >> implementing effects. However, I find the syntax way too > >> verbose for simple aggregate properties like colors. With the > >> proposed changes effect files can be property lists, and > >> effects values can easily be represented as property trees, > >> while still preserving a concise syntax. > >> > >> I'm not proposing to change any existing property to an > >> extended property. > > > > This strikes me as an extremely bad idea. > > > > The property tree isn't just used for FG's internal workings > > but also as a consistent interface to the external world, the > > consistency coming from explicitly identifying scalar data, > > removing any possibility of ambiguity in exactly what data > > you're dealing with. > > > > However, the data items in the compound datatypes proposed will > > only be implicitly identified; how can this be a good thing? > > Assuming for minute that this change would be adapted widely... I > would wager that for the data types we're talking about, the > order of individual components is almost universally understood. > Who writes "bgr" or "yzx" in human readable files?
The problem isn't that someone might mistakenly write "bgr" instead of "rgb" but that with scalar values the issue simply doesn't even arise. Introducing compound datatypes makes it possible to make a mistake where it was impossible to make one before. > > > I can't accept that the current scalar datatype handling is > > "way too verbose for simple aggregate properties like colors" > > In this specific example we've just gone down a single level, > > to handle just three values, and in the Vec4 types you're not > > descending any deeper but just adding a single extra value - > > just how much of an overhead is there in handling that, that > > makes it "way too verbose? > > It's the human overhead in ploughing through all the extraneous > crap -- words and symbols around every data item -- that I'm > worried about. For the types that will be used in the effects > files, all that is completely redundant. You're saying that as though you have to deal with hundreds or even thousands items when it's really just three or four. I can't help thinking that you're exaggerating just a little bit. We're spending more time and effort arguing the pros and cons over it than it would actually take anyone to code the three or four items. > > > And why is verbosity a problem anyway? Sure, it may mean more > > keystrokes for the coder producing the software but the main > > purpose of producing the software is so that it can be used by > > the user. By reducing verbosity for the primary-developer > > though, you're just passing the burden on to the > > user-developer. The primary-developer should only have to > > 'suffer' from having to deal with this verbosity just once, > > when he writes the code, but from that point onwards, everyone > > else who needs to use that data has to duplicate effort to deal > > with it. > > I'm not sure who you're referring to as "developers" here. When I > first read this I thought you meant "C++ coder" and thought you > had completely missed the mark. But I think you're talking about > XML file reader/modifier/hacker. I assure you that the users of > effects files will be completely comfortable with my proposed > syntax. It's the same as used in Ogre materials, Collada, Direct > X, etc. Yes, I was talking from the point of view of an aircraft developer, but I'm also thinking of all the other projects that use FG as just one of their elements - the property tree is how we all talk to FG and interact with it - it's the interface we use and one of it's best features is that the data is returned directly and doesn't need to be parsed/extracted. Once you've written the C++ code that outputs this data, how often will you need to go back and deal with it's verbosity? Every aircraft that accesses that data though, will need to incorporate extra code to parse it. It just seems that in return for reducing a small burden that will be infrequently experienced, you'll be imposing a greater and more frequent burden upon the software users. > > > In conclusion, this proposal just seems designed to slightly > > reduce the workload for the primary-developer at the expense of > > increasing the workload for the user-developers, at the same > > time rendering the interface inconsistent and ambiguous. > > I don't agree. Perhaps our points of view differ depending on > whether we're used to treating types like colors as a composition > of scalar values or as an indivisible whole. > > Tim In practice, you can only manipulate colours as a set of scalar values. Furthermore, I suspect the most common manipulation is to alpha values, where you're only interested in changing that single value; where's the benefit of having to read, parse and then write four values when only one needs reading and then changing? LeeE ------------------------------------------------------------------------------ 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
