Re: How to completely release every object allocated when opening a NIB file ?
Re: How to completely release every object allocated when opening a NIB file ?
- Subject: Re: How to completely release every object allocated when opening a NIB file ?
- From: Jörn Salewski <email@hidden>
- Date: Wed, 14 Jan 2004 06:25:11 +0100
am 14.01.2004 5:12 Uhr schrieb Charles Srstka unter
email@hidden:
>
The constant defined in NSNib is NSNibTopLevelObjects, not
>
NSTopLevelObjects. What's more, NSNibTopLevelObjects of course appears
>
in the binary for 10.3, but doing a grep on the 10.1 Frameworks folder
>
yields nothing. NSTopLevelObjects, on the other hand, does appear in
>
the AppKit binary in both 10.1 and 10.3, but as it seems to be
>
undocumented, who knows if it will go away in some future release.
>
Taking the case with the nib owner key. This at least is documented, but the
documetation doesn't talk about a defined NSOwner but it only mentions
@"NSOwner".
The comments to NSNibOwner and NSNibTopLevelObjects in 10.3 NSNib.h are very
interesting I think:
// ** External Name Table Keys **
// Note: the actual values of these defines match the
// older NSBundle nib loading values for backward compatibility.
// This should specify the nib file's owner (required)
APPKIT_EXTERN NSString *NSNibOwner;
// This should be an NSMutableArray that will be filled with the top level
objects
// of the newly instantiated nib (opional)
APPKIT_EXTERN NSString *NSNibTopLevelObjects;
The first comment doesn't seem to be made only for Apple internally, but
that they expect others to use "older NSBundle nib loading values" (whatever
they are) and that these older values can safely be used in the future
(since the new values match them).
Therefor I'm inclined to believe that somewhere in Apples code one would
find:
NSString *NSNibOwner = @"NSOwner";
NSString *NSNibTopLevelObjects = @"NSTopLevelObjects";
>
Which brings me to the point, isn't this badly broken? The point of
>
Cocoa's reference counting was that you were supposed to only have to
>
release something if you specifically called init or retain on it. As
>
it is, the rule has to be extended to: "You only need to release
>
something if you called init or retain on it. Except for top-level
>
objects in nib files, which you own and have to release, even though
>
you didn't call retain or init, even though your code might not even
>
*know* about those objects, and even though the nib file could be
>
edited after you write the code and your code could have to deal with
>
objects that didn't *exist* at the time the code was written. Oh, and
>
forget this rule for NSDocument's nib file, which *will* release the
>
objects, causing you to crash if you try to release them. So don't
>
release those! But do release everything in everything other nib file.
>
Wait, unless you use a NSWindowController, because *it* will release
>
the nib file objects... but oh, Cocoa's memory management is easy!"
>
Try explaining *that* to a newbie and expecting him/her to keep it
>
straight.
Don't forget to explain what top level objects are. As far as I can see this
definition is missing in Apples documentation too. They frequently talk
about top level objects without ever telling you what they are. Basically
you have two choices:
a) explicitly releasing objects you think belong to an undocumented group
of those top level objects (you'll notice soon if you release to much, but
you'll leak memory if you don't.)
b) using some apparently undocumented feature to collect those objects.
Either way you take, you are left on undocumented grounds as it seems.
Previously I haven't noticed that @"NSTopLevelObjects" is not documented. I
think I got this key from earlier cocoa-dev posts. Maybe it's worth having a
look at the archives.
Ahh, and secondly. Don't forget to tell your newbie the subtle exception if
you mark the release-on-close checkbox of a window in the nib file ;-)
Yours,
Joern
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.