It's not because of the 'misconception' about having to amend/convert existing stuff to use the new data types that I think introducing these new datatypes is a bad idea.
It is because: 1. It introduces the scope for errors where currently no scope exists because the identification of each value is only implicit and derived from the ordering of the data within the type. This means it will therefore become possible to specify the data in the incorrect order, whereas with explicitly identified data items this cannot happen. Thus a new scope for errors is introduced where there was none. 2. As Ron mentioned, the property tree currently presents data in a consistent and atomic way but introducing these compound datatypes would break that. I can't go along with your assertion that strings are really just arrays of characters; the data is the string, not the characters that make up the string. You could as easily argue that Int's were arrays of digits and floats/doubles were linked pairs of arrays of digits and then, for example, start specifying a series switch states as '10011010' instead of identifying each one explicitly. Then see point 1. above again. 3. The new compound datatypes are just about how data is represented in the property tree and I can't see how they would make something possible that would otherwise be impossible without them. As such, they just seem like duplication to me. 4. If the new datatypes were to be accepted, and given that they are just another way of representing data, is it intended to prevent people from using them in other areas, such as within model animation files? Will it be possible to use either representation anywhere and if so, how do we choose which representation to use where? What will happen if someone tries to use the wrong representation in the wrong place? Doesn't point 1. above also apply again? No, the issue I have with the new datatypes is not that it would be a lot of work to change existing stuff. It is because it seems like bad design; it doesn't seem to be required to enable an otherwise impossible feature but at the same time introduces the scope for new errors whilst breaking the consistency of the current data atomicity. LeeE On Sunday 05 April 2009, Curtis Olson wrote: > I agree that the property system is for generic data ... so > adding color_vectors or position_vectors is really out of the > scope of what it should be intended for. This is too specific > and I agree that it creates a mess and there's then no good place > to draw the line when the next person comes along and wants to > add some other specific aggregate structure. > > However, if the proposal is to add support for storing generic > float (or double, or int) arrays in the property system, then I > think that could be supported. Again we already support > character arrays (although as has been pointed out, without an > interface to be able to access individual elements of the array.) > > Two misconceptions I am hearing, and maybe Tim can respond to > these: > > 1. Adding float arrays to the property system for the purpose of > representing colors and vectors will require all modelers to > convert all their existing models, structures, and code to the > new system. There seems to be a lot of push back from modelers > based on this fear, and I wonder if this is going to be the case? > If so, then they have a point. Is this a misconception of Tim's > proposal or not? > > 2. Adding float/double arrays to the property system will also > require adding a myriad of operations on those arrays ... do we > need to now implement a full suite of vector and matrix math > operations inside the property system. > > I just want to keep the discussion clear and make sure that we > are all on the same page with what we are talking about here. I > sense that a large amount of negative imagination is creeping > into the discussion, so let's clarify if these fears are founded > or not? > > Regards, > > Curt. > > On Sun, Apr 5, 2009 at 9:19 AM, wrote: > > > Except for a few inconsistencies in xml style that already > > > have been mentioned I think it's worth adding it then. > > > > Maybe I am misunderstanding this issue, but I have been > > involved in using FlightGear at work for a number of simulation > > related projects during the last couple of years, and to me > > some things are still unclear: > > > > Personally, my understanding of the property tree is that of an > > IPC enabling mechanism, that ties together all FlightGear > > subsystems and often also many non-FlightGear related > > tools/software even outside its own address space. > > > > So from my point of view, it is seems important to keep in mind > > that the property tree is not only about global variable > > storage but that it's also FlightGear's one and only > > standardized IPC mechanism, all subsystems and many FlightGear > > related tools that work outside the fgfs process space > > communicate with each other using the property tree and its > > natively supported types. > > > > With this in mind, it really seems of paramount importance that > > all property tree users (fgfs subsystems or external tools) > > have a concept and way of dealing with the native data types > > represented in the property tree. This exactly is it what makes > > the property tree, and more generally, FlightGear so intuitive, > > unobfuscated, powerful and easy to extend. This has been my > > experience when interfacing FlightGear to other software. > > > > Enhancing the property tree to support new component-specific > > native types that cannot be directly accessed, manipulated or > > processed by all or at least many other FlightGear related > > subsystems and tools seems like a troubling idea to me, in > > particular when it's not even foreseeable that other subsystems > > are going to develop a demand to also benefit from such a > > change eventually (just because they can already do all of this > > simply by using a more verbose, user-friendly and > > self-explanatory format that's been in use for years). > > > > Just think about some of the more complex systems that depend > > on having a full understanding of all property tree data and > > types, such as Nasal, the XML protocol system, the telnet > > interface to the property tree or the multiplayer system, all > > of which depend on working with arbitrary native property > > types. > > > > In its current form the property tree and its potential is > > virtually unrestricted and many new features were and still can > > be implemented on top of this very genericity without requiring > > modifications to the core implementation of the property tree. > > > > The natural tree-structure of XML and the natively supported > > data types allow users to emulate even complex data structures > > just by using the existing -admittedly verbose- syntax. But > > that's simply the cost of directly mapping XML to the key/value > > format used by the property tree. > > > > So the question really appears to be if FlightGear wants to end > > up with property types that are so purpose- and system-specific > > that only certain subsystems really know how to deal with them, > > essentially resulting in "second class properties" that cannot > > be processed by much of the currently existing FlightGear > > infrastructure? > > Basically, this is introducing a form of forced encapsulation > > into the property tree. > > > > I am not trying to dramatize this issue, this is just my > > current understanding of the likely repercussions. > > > > For the time being, the property tree system doesn't have a > > single feature (to my knowledge) that is really specific to > > just one single FlightGear component or purpose - the property > > tree code has been so well generalized that it can be equally > > used by all components, without restrictions. It just consists > > of primitives, building blocks that can be used to model more > > complex data structures on top of it. > > > > Changing this would probably not only result in second class > > properties but eventually also in second class subsystems and > > after some time also in second class software interfaces and > > tools, because not every property tree "user" may be able to > > deal with all of FlightGear's internals represented by such > > non-POD types. > > > > According to my understanding of the situation, this would be a > > very unfortunate situation. > > > > It seems logical and plausible from that from this point of > > view, this proposal would actually contribute to obfuscating > > FlightGear and degrading the current property tree system, > > which really is currently fully self-documenting and 100% open > > and accessible to all components. > > > > So adding new non-POD types raises not only the issue of > > inter-type conversions for such non-POD types, but also the > > issue of serialization for persistence/network transfer > > purposes (i.e. custom protocols, multiplayer). It seems to me, > > such additions may cause a whole new dimension of potential > > issues. > > > > It's obvious and understandable that, in the light of Tim > > Moore's very significant and highly appreciated contributions > > to FlightGear, it is very easy to overlook the potential > > architectural implications and ramifications in this proposal. > > > > Even if this is ultimately accepted for the time being: where > > is the line to be drawn? > > > > Are there going to be aggregate types that can be directly > > mapped to C++ data structures such as arrays, structs or > > unions? > > > > Or might there even be binary blobs one day in the property > > tree in order to directly store textures, audio files or 3D > > models and animations in the property tree? > > I'm sure there are scenarios where having support for something > > like that would be useful. > > > > And how are those non-POD types going to be serialized (i.e. > > for network or XML use)? > > > > Finally, it seems very likely that there are always going to be > > more aircraft-set.xml files than there'll ever be XML/effects > > files - if aircraft developers manage to cope with the > > verbosity of these aircraft-related XML files, they surely > > won't bother too much about some self-documenting explicitness > > in an XML/effects files? > > > > best regards > > > > -hfitz > > > > ---------- > > Get even more from your private email hosting service. Visit > > the pages of Zoner Software and download your free copy of the > > Zoner Photo Studio 11 program today! Learn more - > > www.zoner.com<http://www.zoner.com/ww-en/photo-studio-professio > >nal/>. > > > > > > > > --------------------------------------------------------------- > >--------------- > > > > _______________________________________________ > > Flightgear-devel mailing list > > Flightgear-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
