On May 18, 2015, at 10:52 , Britt Durbrow <bdurb...@rattlesnakehillsoftworks.com> wrote: > > Is the reasoning that: > > 1: Not under ARC; > 2: There is one known strong link to an object; > 3: retainCount returned 1 > > Therefore, the only strong link to the object is the known strong link > specified in item 2. > > … is that not valid? If not, why not?
No, I think not. There are at least 2 dimensions of variability that can break this reasoning: time and threads. Furthermore, the assumption that your peek at the object state will reliably (or ever) return a retain count of 1 as opposed to (say) 2 is flawed. For example, if the object is in the autorelease pool, you’ll see a count of at least 2, but you won’t be able to deduce why. > Note that I am *not* asserting that it will be deallocated, just that nothing > else has a strong link to it that could use it in a detrimental way (most > importantly, mutate it). Just so, so I think you need to disentangle the following things: 1. Whether an object is in your data model’s object graph. Note that there is an implicit extended object graph beyond the references between the objects themselves. For example, if an object is (say) set as the delegate of some service, but is no longer in your actual object graph, it may get a delegate message that causes it to intrude unexpectedly. In that case, it’s effectively still in your object graph. 2. Whether an object is alive (has or has not reached dealloc). You actually don’t care about this, though we haven’t convinced you of that yet. ;) 3. Whether an object is discardable from memory in case of (for example) memory pressure. Currently, you’re trying to achieve #1 and #3 by thinking in terms of #2. However, #2 is the one thing you can’t actually control — in any very direct and deterministic way. You currently have an app that controls #1 directly. You’ve also been offered several ways of controlling #3 directly, one of which is to forcibly increment or decrement the retain count in deterministic ways. Your unease is making you think of this as an attempt at #2, but it’s not. It’s really #3. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
