Doug Simons wrote: > Now, at some point in time every object in the application with a direct > reference to Ancestor is released, causing Ancestor to be fully released and > (under the scheme you're proposing) deallocated. Suddenly and without > warning, through no action of its own, Son is detached and made an orphan, > with no parent, and no way to access its siblings even though some of them > may already be instantiated as Obj-C objects, which are now similarly > orphaned. > > Perhaps that's not the most likely scenario, but I don't think it's entirely > far-fetched. The only solution I see for such a scenario is for the > application author to have Son keep and retain a reference to Ancestor for as > long as Son is around -- but then you've suddenly created exactly the kind of > retain loop between Son and Ancestor that the current NSXMLNode memory > management scheme goes to great lengths to resolve, so it will all "just > work" for the application developer.
I don't understand why there should be a retain loop here. As far as I understood from your description, ancestor and son are independent objects. If you want to be able to traverse the whole document tree from the son object you should retain the ancestor object or the document root from the son object. But I see no reason why either any of the tree nodes or the ancestor object should retain the son object. > Under the current scheme, as long as the application holds a retain on any > Obj-C object anywhere in the tree, the entire underlying tree structure and > any other Obj-C objects that have been instantiated as part of it are kept in > memory. When the final "external" (from outside of the tree) retain is > released, the entire structure and all of the objects are freed. A fair bit > of complexity internal to the framework to make using the framework simple. > > So I'm disappointed to hear that Cocoa does it the cheap way! I appreciate > that that approach will be simpler to implement and easier to understand the > internal GNUstep code, but I wonder if it would be at all worthwhile at this > point to allow a "WholeTreeIntegrity" flag to enable a developer to choose > either memory behavior. Any thoughts? I think keeping a pointer to the document root in the object is an easy alternative to that. So I'm a bit skeptical whether the additional complexity is really worth the effort. On the other hand, you already did invest much of the effort :-) Wolfgang _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
