Melchior FRANZ wrote:
> Well, the theory is that the property tree is there to
> inspect/access values. And the idea is that a remove function
> shouldn't only detach property nodes that are then secretly used
> behind the users back. If you want them to stay, don't remove them.
Reference counting isn't about "removal" or "detachment". It is a low
level API convention that deals with *allocation*. This argument
seems to be confusing the two.
In this particular case, no one "wants [the node] to stay". But some
parts of the code may need to hold a *pointer* to the node in a place
that is not accessible to the code making the removeChild() call. So
you decrement the refcount instead during detachment (not
destruction!), and the *library* decides when to destroy (not detach!)
Again: "destroy" (low level C++ concept) is not the same thing as
"remove" (high level property concept). Think about it this way and
things should be clearer.
> > When they free their reference, then it gets deleted.
> But it doesn't. That's the whole point. The SGPropertyNode_ptr
> destructor doesn't remove the node's children.
Again, the disconnect: I'm talking about deletion (i.e. whether the
memory is freed or leaked), and you are talking about logical property
stuff like where the node appears in the tree. These aren't the same
It might not be desirable to have SGPropertyNode objects that are
"detached" from the property but still be "live" in the sense that
reachable pointers can find them. You might hate this concept. It
might be bad design. BUT IT MUST BE LEGAL! Otherwise you cannot have
garbage collected property references. Otherwise you cannot have
automatic deletion across C++ exceptions. Otherwise you cannot put a
property node pointer on the stack at all and expect it not to leak.
Otherwise you get NO VALUE WHATSOEVER from the nice refcounting
implementation that David Megginson gave us.
> > That's not possible in Nasal.
> OK. So we are actually talking about a Nasal problem? :-}
It's not possible. It can't be fixed. You can blame me personally if
you want, but nothing will make the current removeChild()
implementation compatible with garbage collected Nasal nodes. The
latter depends on the reference counting semantics*, while the former
depends on a special case side effect** of our implementation. These
are fundamentally incompatible metaphors. Pick one to eject, you
can't have them both.
* A standard concept that David Megginson implemented in the standard
way; I had no trouble understanding what a SGPropertyNode_ptr was or
how to use it, for example. As a result, Nasal has access to
leak-proof and garbage-proof handles to property nodes (something
that would basically be impossible without the refcount mechanism or
something like it). This, I argue, is a feature and not a bug.
** Specifically, it assumes that the parent/child relationship in the
property try is the *only* context in which the reference counting
will be used, which is silly and breaks the really nice features
that refcounting gives you. It is also false; if that were the
case SGPropertyNode_ptr would not be a public API. Note all the
other places that use it.
Seriously: the removeChild() method is just buggy. It should never
have cared about refcounting at all.
Flightgear-devel mailing list