On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote:
If so, seems like we're kind of shooting ourselves in the foot .... or
am I just being super-anal and should just poll them as Jim Wilson
suggests?
This is a good discussion to start. I'm inclined to eliminate tying
altogether and have every module set properties explicitly; what does
everyone else think?
Couldn't agree more, but I think this is likely to be unpopular. We can keep tying if we have an efficient 'notifyTiedValueChanged' method, which should be a no-op if there are no change-listeners registered on the property, and otherwise should run through them.
Tony Peden wrote,
I'd really like to see tying stay in. I'm not sure we ever would have
incorporated the property tree into JSBSim without it.
I don't understand why
xPosNode.setFloatValue( xxxxx )
is so much worse than
my_tied_xPos_float = yyyy
apart from being a bit verbose. And the advantage is, it forces you to appreciate (when you do the set) that some extra working is going to get done (listeners being invoked for now, who knows what else in the future)
Jim Wilson wrote,
Ummm...it's not polling, it's just updating the data. Same as many of the
subsystems do every frame. Polling is a contious loop that waits for
something to happen. Like I said, if we're not displaying the prop_picker
then it should
not be updated.
Well, I take polling to mean, going and looking at a value over and over again (one 'look' per frame). That works fine, and I'm *not* trying to argue an efficiency point (sorry if my original email came across that way, since that's how most people seem to have taken it). It's an issue of dataflow in the program : should it be driven by the people updating the values, or by people reading them?
Basically, I can envisage lots of things the ChangeListener API is perfect for, whether you're observing a value that changes one a week or 50 times a second, but right now those things won't work because some % of the properties don't tell you they've changed. Now, we could always flag some properties as 'immediate' I suppose, but that seems like a hack. There's nothing wrong with the current API, we just ought to make all the property nodes meet the contract it defines, or we need to remove change listeners from the API and have everyone poll / update as you suggest.
H&H
James
--
That which does not kill me has poor aim
