On Sep 9, 2013, at 9:44 , Kyle Sluder <k...@ksluder.com> wrote:
> Thirded.
Countered. :-)
> I thought I wouldn't like it.
I thought I would LOVE it, and when I actually used it was “meh”. Not just the
additional rules/complexity when dealing with the C side of things (which I do
quite a bit), but more importantly it just didn’t make any difference on the
upside, for me. Which surprised me greatly.
> As soon as I didn't have to manage retains and releases of temporary objects,
> the discipline completely left my mind.
Retains and release of temporary objects? Did you do things like the following?
id myTemp = [newObject retain];
...do stuff...
[myTemp release]
I have to admit that when I saw (client) code like that, I also found it
problematic, difficult to understand and regularly peppered with errors.
The pattern I adopted long ago to avoid that sort of situation is to have an
instance variable for my temps, in which case the code becomes:
[self setTemp:newObject];
… do stuff …
[self setTemp:nil];
or if you prefer dot syntax:
self.temp = newObject;
… do stuff …
self.temp = nil;
Even if you forget nilling, you at most have an extended lifetime of an object,
not a leak. I also generally do the same in initialization code (but not in
dealloc). For me, that simply got rid of reference-counting pain. Completely.
Memory management is mediated by accessors, always. And accessors are
generated.
I am starting to think that this may explain the (vast) difference in
perception of ARC, at least it’s an explanation I can understand: if you made
the switch to always having reference counting mediated by accessors, RC goes
away as a pain point. If you haven’t, it’s probably a huge pain that ARC
removes.
Cheers,
Marcel
_______________________________________________
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
