Melchior FRANZ wrote:
> Andy Ross wrote:
> > * In this case: using the reference count to tell whether or not the
> > node is "in the tree" or "detached".
> Actually, it prevents nodes from disappearing from our property node
> memory representation -- which is the property tree.
It sounds to me like these are saying exactly the same thing.
Guys, please: The reference count is a count of pointers to an object.
Nothing more. Making it mean anything else is *not* a reference
Reference counting is a well-established idiom. Plib uses it. The
auto_ptr uses it. It apperas in pretty much every textbook on C++.
When I saw that the David's SGPropertyNode class implemented a
refcounted pointer, I knew *exactly* how to use it, because it worked
like all the other ones I have seen. And guess what? It worked.
The new "reference count" semantics are not the same as the ones plib
uses. They are not the same as auto_ptr, or the treatments in
textbooks. And therefore they are confusing, and cause bugs.
Changing the meanings of well-established idioms in critical
infrastructure like the property system is just really bad design.
Sorry, but it is. If you insist on re-purposing the reference count,
then please rename it to something else (that is, after you've removed
the props.Node interface from Nasal).
> Fixing the new one is, of course, desirable *if* it's broken.
Huh? This whole discussion started when you reported that after the
new changes, removing property nodes from Nasal was broken. The
reason is that the change broke the refcount semantics that Nasal is
Flightgear-devel mailing list