On 4 Mar 2011, at 01:10, Matt Neuburg wrote: > On Tue, 01 Mar 2011 16:15:09 +0700, "Gerriet M. Denkmann" > <gerr...@mdenkmann.de> said: >> >> On 1 Mar 2011, at 15:53, Kyle Sluder wrote: >> >>> On Tue, Mar 1, 2011 at 12:45 AM, Gerriet M. Denkmann >>> <gerr...@mdenkmann.de> wrote: >>>> So obviously NSAttributedString does NOT return [ [ aFont retain ] >>>> autorelease ] but just some internal pointer. >>>> >>>> Is this documented somewhere? >>> >>> In the Memory Management Programming Guide: >>> http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/MemoryMgmt/Articles/mmAccessorMethods.html%23//apple_ref/doc/uid/TP40003539-SW6 >>> >>> --Kyle Sluder >> >> As far as I can see, this article talks about different ways to implement >> setters and getters. >> Do you want to imply that, whenever I get some object from AppKit, I have to >> retain it until I no longer need it? >> >> Would be a safe thing to do. But also tedious. And in all my past experience >> this was never necessary. >> So I thought that the "Technique 1" of the linked article (returning >> [[someObject retain] autorelease]) was the standart practice employed by >> AppKit. > > I've been thinking about this exchange, and I would propose that you consider > it like this: > > Suppose you've got an NSArray and you fetch its element objectAtIndex:0. And > suppose you now let go of the array (release) and it is destroyed. Do you > expect the fetched element to persist without your having retained it? You do > not; you know darned well that a collection doesn't behave like that. The > collection *owns* its elements and will release them when it is released. All > you got when you called objectAtIndex:0 was a pointer. If you want a share in > its ownership, you must *take* ownership. > > Here's another example. Suppose you've got a UIView and you ask for its > subviews. Do you imagine that asking for this property gives you ownership of > those subviews? You do not. Similarly for *any* property of *any* object. You > *never* imagine that a fetched property is somehow magically *giving* you > ownership; it's just showing you a value. > > So what I'm trying to show you is that when you've got an object that owns > stuff, you *never* expect that that object will dispense the stuff it owns > while handing you a share in ownership. You *always* take ownership if you > want that stuff to persist beyond the object that dispenses them. Ownership > is *never* something you are magically given. It is always something that you > must take if you want it.
Yes, I fully agree. But, taking my original example: NSAttributedString * attributedString = ... NSFont *aFont = [ attributedString attribute: NSFontAttributeName atIndex: 0 effectiveRange: NULL ]; NSString *fontName = [aFont fontName]; [ attributedString release ]; Now aFont no longer exists. So fontName, being a property of the no longer existing aFont, should have vanished also, shouldn't it? But in my case, fontName is still valid. Maybe the fontName method really returns [[fontName retain]autorelease] (as I wrongly assumed all methods did) or some magical entity keeps a handle on all font names, or this name is a constant string decared in AppKit, or whatever. But this did add to my confusion. Kind regards, Gerriet. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
