Re: [Flightgear-devel] ANN: SGPropertyChangeListener
David Megginson wrote: > James Turner writes: > > Certainly this point needs to be emphasized, otherwise there will > > be a situation where someone moves some code from using non-tied to > > tied props (for whatever reason) and the behavior of every system > > that depends on those properties subtly changes. This is a worst > > case scenario, naturally ... > > It's a pretty credible one. Right now, I'm looking at listeners > mainly as an alternative to tying, but soon we'll want to use them for > other purposes as well. I was thinking about using call-back functions for the sound manager. It seems to me this comes pretty close to implementing just that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: SGPropertyChangeListener
James Turner writes:
> > 2. If a property has been added or removed, it is the property's
> >parent.
>
> Hmm, how is the listener meant to work this out? Seems like you'd
> be better with a bigger interface (change / add_child / rmv_child)
> and default { } impls so people can ignore changes the don't care
> about.
Yes, I'm thinking about that, but I haven't decided the best way to
manage it yet.
> For the add / remove cases, you'd like to know the parent
> node and the child node, I guess.
Or perhaps just the path to the parent or child node.
> > The property manager automatically fires change events for non-tied
> > properties; for properties with tied values, the subsystem to which
> > the properties are tied must trigger change events manually with
> >
> > node->fireChangeEvent();
> >
> > (or not, as desired).
>
> This seems like an opportunity for bugs, though I can't think of a
> better solution either.
I'm getting less and less fond of tied properties as we go on.
> Certainly this point needs to be emphasized, otherwise there will
> be a situation where someone moves some code from using non-tied to
> tied props (for whatever reason) and the behavior of every system
> that depends on those properties subtly changes. This is a worst
> case scenario, naturally ...
It's a pretty credible one. Right now, I'm looking at listeners
mainly as an alternative to tying, but soon we'll want to use them for
other purposes as well.
> Just though of an extreme solution to this. In a debug build, the props
> code could run a check each frame against the previous and current
> values of every tied, event-listened prop (i.e not that many). If it
> sees a value change without the event change being fired, it could log a
> warning / error.
>
> That's a lot of effort, though.
Yes, that's pretty severe, and it could trigger a lot of processing if
the tied getter has side effects.
> > This addition adds no measurable overhead (just a null pointer check)
> > when listeners are not enabled; when they are enabled, the overhead
> > will depend on the listeners.
>
> Hmm, does this mean we're limited to one listener per node?
No, it's a lazy vector pointer (not allocated until the first listener
is added).
On a separate note, I think that I can do a little fancy stuff with
the listener to help with memory management -- if the abstract base
class keeps a back pointer to every property node it's listening to,
then the destructor could unregister it automatically to avoid
dangling pointers. I'll have to look into that.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: SGPropertyChangeListener
On Tuesday, June 18, 2002, at 02:38 am, David Megginson wrote:
>
> The node argument is as follows:
>
> 1. If the value of an existing property node has been modified, it is
>the node itself.
>
> 2. If a property has been added or removed, it is the property's
>parent.
Hmm, how is the listener meant to work this out? Seems like you'd be
better with a bigger interface (change / add_child / rmv_child) and
default { } impls so people can ignore changes the don't care about. For
the add / remove cases, you'd like to know the parent node and the child
node, I guess.
>
> To add a listener to a node (there's not yet any remove
> functionality), you simply use the SGPropertyNode::addChangeListener
> method:
>
> node->addChangeListener(this);
>
> The property manager automatically fires change events for non-tied
> properties; for properties with tied values, the subsystem to which
> the properties are tied must trigger change events manually with
>
> node->fireChangeEvent();
>
> (or not, as desired).
This seems like an opportunity for bugs, though I can't think of a
better solution either. Certainly this point needs to be emphasized,
otherwise there will be a situation where someone moves some code from
using non-tied to tied props (for whatever reason) and the behavior of
every system that depends on those properties subtly changes. This is a
worst case scenario, naturally ...
Just though of an extreme solution to this. In a debug build, the props
code could run a check each frame against the previous and current
values of every tied, event-listened prop (i.e not that many). If it
sees a value change without the event change being fired, it could log a
warning / error.
That's a lot of effort, though.
>
> This addition adds no measurable overhead (just a null pointer check)
> when listeners are not enabled; when they are enabled, the overhead
> will depend on the listeners.
Hmm, does this mean we're limited to one listener per node?
H&H
James
Anyone who considers arithmetical methods of producing random digits is,
of course, in a state of sin. -- John Von Neumann, 1951
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
