On Sun, Apr 5, 2009 at 2:44 AM, Ron Jensen <w...@jentronics.com> wrote:
> To claim the property system supports character arrays is wrong, and > somewhat disingenuous. The property system supports strings as atomic > units. You can not access the nth character of a string nor can you > change only the nth character of a string like you could if it were an > array. I'm not sure I agree there ... while the facts you state are true, it is also true that the property system can be used to store arrays of characters. Is Tim's proposal to add arrays of float's along with a full set of operations on the individual elements? The property system serves as a human interface as well as interfacing > between subsystems. Melchior expressed his very deep, very real, very > valid concerns better than I can in his initial e-mail > > http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21558.html > > I have heard nothing to address his vital questions. > How should such a property be displayed in the property browser? Or the > web interface? Or the telnet interface? Let me say a couple things here. How is floating point input handled right now? All these interfaces input the new value as a character array and then based on previous knowledge of the data type, convert that string to the appropriate type. If there's no other indication of the data type, the value is left in the form of a character array. How would it be any different in this case? We would need some code to parse the string into the appropriate data type if the property has been typed as a float array. Likewise, the telnet/web interface need to convert the numeric values to strings before outputting them. Again, in the case of a floating point array, how would this be any different? Slightly more complex, but if some conventions are chosen (like putting a space between the numbers as Tim has proposed, then this can be done unambiguously and consistently.) I don't want to be dismissive of this concern, but it seems pretty minor to me? Am I missing something here? Can you suggest a case where this would be confusing or would break something? 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? How will we input VEC3 properties > via the property browser? By Tim's proposal you would do this like this: "0.1 2.4 -3.0 1.0" > As he is currently the primary coder in the GUI and interface department > he is in the best position to foresee problems. I urge you to trust his > judgment. A big problem here (in my view) is that neither side is being as clear as they need to be with this discussion. We can't just assert there will be a problem and leave it at that. I'm still hoping someone can list a specific example of how these interfaces will break. Or am I the only one in the room who doesn't see the obvious cases? > Count me in as "some people" From the e-mail traffic on this list, > "some people" also include some very talented developers: > > Jon Berndt: > "I always came back to the conclusion that (vectors) would be a really > bad idea. And it still is." I hate to put words in people's mouths, but let me try to do this fairly.... The primary reason I heard from Jon, is that he was thinking this will require a huge expansion in creating operators that manipulate these vectors ... and do all the different vector math operations. I think that's a misconception, but maybe I missed something in Tim's proposal? If true, then I agree with Jon's conclusion, but I think this is a misconception with the proposal. Erik Hofman: > "I have the feeling this will become a developers nightmare" > > LeeE: > "This strikes me as an extremely bad idea." > > Stuart Buchanan: > "I'm very concerned about making the external interfaces more complex. > One of the huge strengths of the property system at present is its > simplicity, and I think that would be lost." If these folks are speaking from a modeler's perspective and expecting that this proposal will require them to redo all the color and vector properties in all their modeling work, along with rewriting all the corresponding nasal code, then yes, this would be a horribly unnecessary thing to force on the FlightGear community. But again, I hope Tim can respond when he has a chance, because I think this is a misconception with Tim's proposal. If these modelers have correctly interpreted Tim's proposal, then I'd side with the modelers, but I suspect this is a misinterpretation of the proposal. > Csaba Halász: > "I like that the color components are written out, less possibility for > confusion (RGBA? ARGB? BGRA?)" Can anyone point to any place within the FlightGear project where we don't use RGBA? And if so, why does the code need to do it differently? If we write out the color components in random orders and inconsistenly throughout the code, then this could be a point, but I can't think of one case where we don't use RGBA ... and that order is done consistently throughout the world of OpenGL and all the accociated tools. There may be image formats that use othe orderings but show me a place in the FlightGear code where we do anything other that RGBA? Again, I'm very open to good clear discussion. I don't want random aggregate types added to the property system. But this isn't what is being proposed by my understanding. Let's clear up the misconcpetions about the proposal, and then if there are still problems, lets come up with some solid logic and solid examples. Melchoir has done much to enhance the usability and elegance of most of > our systems. Initially I was not a fan of all the nasal code, but I > have come to greatly appreciate its functionality and power. There is nothing to disagree with here, but it's not a reason why Tim's proposal is good or bad. > It comes down to human usability of the property tree. We have taken > great pains to ensure the tree is self-documenting and consistent. That > is why we have "fuel-level-lbs" instead of just "fuel". What Tim has > proposed is sticking in unlabeled, undocumented values. Values that can > not be changed via the current property browser or telnet interface. This paragraph seems to be full of misconception. Why would we not be able to change these values in the property browser or telnet interface? Why would we not choose names that clearly indicate the type. For instance: telnet interface> ls /path/to/some/color-rgba 0.5 0.5 0.5 1.0 telnet interface> set /path/to/some/color-rgba 0.6 0.6 0.6 1.0 How is this unlabeled? Undocumented? How is this ambiguous? How is this unclear? In addition, as has been pointed out we already have mechanisms in-place > in the tree to achieve these ends. To quote AnderG, "...you could tie > each of the components of a double vec[4] to properties, e.g. > color/{red,green,blue,alpha}. That would make it possible for the > internal C++ code to use the vector representation while still > preserving a nicely structured and typed property tree for external > access." > The property system does have an ability to handle ordered arrays of children, and that's what I'd suggest, tying property values to array values in this complicated method doesn't seem very useful. But when have we disallowed a feature simply on the basis of there being some other way to accomplish the same thing. I realize this is just one of your points, but I'm not sure the other points really sitck. Again, Curt, if you won't trust Melchior's judgment, trust Jon's, or > Erik's or LeeE's or Stuart's or Csaba's. My concern is that I hear a lot of misconceptions about the proposal embedded in these folks discussion. Melchior's opening volley on this topic sounded reasonable when it lived on an island by itself. But then when you factor in Tim's opening volley, many of Melchior's arguments fell flat and I haven't heard any new ones to boost the "against" position. Tim had good responses for many of these. Honestly, this discussion is full of misconception, misdirection, and politics. I'm getting annoyed by that (not at anyone person in particular, and not at you Ron, just because I'm saying this as part of a response to your message.) In addition, Melchior has played the "I quit the project" over this issue which again reeks of politics and personal fueds, not of any kind of clear thinking ... especially when Melchior won't come back and boost up the arguments that under closer examination don't seem to work very well. I've tried to stay very even on this, but my frustration is finally showing through. Here are my assertions then: 1. Let's not add arbitrary aggregate types to the property system. 2. Let's not polute the property system with operations on the properties (the property system is for data storage only, operations are done with appropriate C or Nasal code.) 3. Why not consider adding support for arbitrary float, double, or integer arrays in the property system? Especially since we already support the idea of storing character arrays. If it doesn't harm any existing code, doesn't complicate any existing interfaces, doesn't require modelers to redo all their work, is purely additive, and is a convenience for one or more developers. These reasons have been more than enough to add tons of code to the project in the past. Why not now? Really, why not? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
