Ron Jensen wrote > > On Sat, 2009-04-04 at 20:54 -0500, Curtis Olson wrote: > > Since the beginning of time, computers have included the concept of > > arrays. > > > > Since the birth of the property system in FlightGear, it has supported > > booleans, integer, floating point, and double floating point types. > > The property system has also always supported character arrays. > > 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. > > 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- > [email protected]/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? > 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? > > 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. > > > > The property system supports implicit conversions between types if > > that is asked for, and always makes it's best attempt. But if you ask > > for something nonsensical or poorly defined, you will get something > > back based on the rules of the system, but it may not make a lot of > > sense. > > > > If you try to extract the floating point value of a string (aka > > character array) you get something back based on the rules of the > > system, but what if you try to retrieve the floating point value of > > "abcdefg". It doesn't make sense, you probably won't get a useful > > answer although you will get something. It's up to the calling > > routine to make sensible requests. It's always been that way, it will > > always be that way. > > > > Now, the message I am getting here is that some people think it's > > unacceptable to also support double or float arrays within the > > property system. > > > > 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." > > 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." > > Csaba Halász: > "I like that the color components are written out, less possibility for > confusion (RGBA? ARGB? BGRA?)" > > > > > It can't be because arrays are messy because we already support > > character arrays. > > > > It can't be because some conversions wouldn't make sense, because we > > already have that situation. > > > > It can't be because it makes the property subsystem too complex, > > because Melchior, to be fair, you are the king of creating very > > complicated systems (with correspondingly high functionality.) I > > don't mean that as a diss ... I'm just observing that you have put > > together some highly complex systems full of subtle nuance within the > > flightgear code base. > > 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. > > > I don't have time to follow along with IRC so I can only see what is > > posted to the mailing list, so I very well could be missing key parts > > of this discussion. But honestly, I am really having trouble > > understanding the objection here. I fail to see what is going to > > break, what is going to end, what harm is going to be done. Is there > > a direct conflict in logic? Is there a non-othogonality in design? > > Is there some behind the scenes fued going on that I'm (thankfully) > > unaware of ... in that case I'll quit trying to draw out logical > > reasons for your objections? I'm married so I'm continually caught > > trying to find logical explanations where there are none. :-) I'm not > > suggesting that's the case here, but if it is, we might as well say it > > clearly so I don't have to waste my time trying to understand what's > > going on. > > > > > > I asked Tim if it would make sense to just support generic double or > > float arrays in the property system ... just like we support character > > arrays. However, he replied that you were even more opposed to that > > than specific color or position array types. Again, I fail to > > understand why. > > > > I could be easily missing something here, I'm not claiming I have an > > all seeing eye. But if someone makes an assertion I don't understand, > > or supports it with reasons that don't make sense to me, I have > > trouble buying that assertion. I've always had that problem, and it's > > my own personal failing I know. I think it's a good thing I didn't > > sign up for military duty here when I was a kid because of that. > > 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. > > 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." > > > > But at the end of the day here, I haven't seen why Tim's contribution > > is unreasonable, or what makes it so different from other > > contributions that have added functionality to the code base. I'm > > trying to guess here at what it might be and haven't stumbled on > > anything I can point to. Really, why is it so unacceptable? > > > > Regards, > > > > Curt. > > 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. >
The implementation of the vec4d type for colour within the effects code is, in the end a design decision, providing it has no effect on the remainder of the property tree. It is my understanding that this is the case. We can let the difficulties and problems speak for themselves. We might be pleasantly surprised. Or Tim will have to fix them. On the other hand, we should not build in arbitrary inconsistencies like strings enclosed in quotes, <less-equals>, tags without units, non-hierarchical tags etc. These can readily be fixed, and IMO the code should not proceed until these small, but important details are fixed. Vivian ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
