On Sat, Apr 4, 2009 at 3:05 AM, Melchior FRANZ <mfr...@aon.at> wrote:
> * Tim Moore -- Saturday 04 April 2009: > > A couple of weeks ago I was asked for a sample of an effects file > > that uses my proposed changes to the property system; > > And a few weeks later I still object to these property changes, and > will do so as often as it is brought up again. And for all the same > reasons! Hi Melchior, Let me ask this on the list. 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. 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. 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. 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. 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. -- Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
