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
