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? > > 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. > > 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. > > 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 ------------------------------------------------------------------------------ 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
