James Turner wrote : > > I do, but this is not the problem (as I understand it). The tie-ing > system is 'low-invasion' for existing code / code which may not be part > of FG, and works well with existing state variables. Your template / > operator overloading fix the syntax, but I sort of think that's worse, > because people may not realize what they're doing will be more > expensive than assigning to a double. But the main problem is people > now need to pull in your template and the property node headers into > places they don't want to. > > The impression I have is that a bunch of code uses 'tieing' to expose > lots of internal variables directly. I'd prefer an explicit > 'publishing' phase, i.e calls to setValue. Of course your template > works fine too, if you're prefer the syntactic sugar.
Frederic BOUVIER wrote : > I see your (rather dogmatic) point but I also see here people that are > not prepared to follow you. My main point is that if there is an interface, > it is supposed to work in all cases and my solution address this point. I realized I may have been more rude than I wanted to be. But I don't think there is a huge penalty here. Classes that are doing tying now must store the SGPropertyNode as a separated pointer for tying and untying. By rewriting the template a little bit, the pointer can be stored only in the template. People that are using tying are JSBsim people and they want their code works standalone. An alternate template without the property connection can do this with no additionnal cost because functions are short and inlined. I don't consider sugar concise syntax that enforce a rule. Look at the SGPropertyNode_ptr class. There are also operator overloading that are counting reference. You could consider it sugar but do you really prefer to increment or decrement values in the code for the sake of seeing what the code is doing. One another benefit of the template/class approach is that the destructor ensure the call to the untie method. Cheers, -Fred _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
