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
