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