On 16 Feb 2014, at 17:06, Jens Alfke <[email protected]> wrote: > On Feb 16, 2014, at 5:27 AM, Kevin Meaney <[email protected]> wrote: > >> Is the only reason for interoperability with manual retain-release code? > > For backward compatibility. Nearly every piece of existing Cocoa code uses > these methods, so there's no way they could take them out.
I didn't say take them out. I said why do they need to return an autoreleased object. Why can't they just return an object like alloc init... does. I think Roland's main point is to ask do they return an autoreleased object. I foolishly assumed they did because a modified version of autorelease was kept with the transition to ARC and my most common experience of dealing with autoreleased objects was via the behaviour of the class methods that create objects. So yes a foolish assumption on my behalf. >> It seems that it creates an unnecessary complication when thinking about >> memory management. Now I'm assuming that any method like: >> NSString *expandedPath = [myPath stringByExpandingTildeInPath]; >> returns an autoreleased string so I need to know this if I'm doing this with >> lots of strings and that I need to put my own autorelease pool in place, >> something I wouldn't have to think about if it wasn't an autoreleased object. > > You don't just need to consider whether methods you call return autoreleased > objects (and as Roland pointed out, it's not always clear whether a returned > object really has been autoreleased or not.) You also need to consider > whether the method you called caused objects to be autoreleased as part of > the work it did. You're missing the question I was trying to ask. Why is autorelease needed at all? If we don't have autorelease then it is precisely clear whether a returned object is autoreleased or not. Something we don't even have to consider. We don't have to worry about whether further down the stack autoreleased objects have been created or not and that in certain situations up the stack we need to add in a autorelease pool. I've read through some of the clang documentation Roland referred to, much of it over my head. I did note that there was some discussion over making sure that objects remain alive over the return boundary and in some cases autorelease was used for this purpose. But I'm still failing to grasp why, if autorelease is being used in some cases for making sure an object remains alive over a return boundary that means there are other ways of dealing with making sure an object remains alive over the return boundary, do we need autorelease? I just feel like I'm missing something. The people at Apple or Clang have decided that keeping autorelease is necessary and I'm struggling to understand why when it seems to me it adds unnecessary complexity. Not major but just another thing that can go wrong if you dont think about it, and so you have to think about it and that takes mental resources away from the job at hand. Kevin _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
