• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Properties, Attributes and Retain+Autorelease
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Properties, Attributes and Retain+Autorelease


  • Subject: Re: Properties, Attributes and Retain+Autorelease
  • From: Markus Hanauska <email@hidden>
  • Date: Wed, 29 Jun 2011 19:27:24 +0200

On 2011-06-29, at 18:09 , Matt Neuburg wrote:

> As I said then, "Ownership is *never* something you are magically given.

Actually I have to correct my previous statement, since it is incorrect. I said:

Following your reasoning, Apple has to re-design Cocoa and re-write all guides and sample code, since no method should ever return a retain+autorelease result, instead all code must always follow the (currently inexistent  rule): "An object returned by another object is only guaranteed to live as long as the object lives that returned it. To extend its lifetime you always have to retain the object".

However, this is far from true. Even if the object stays alive and even if you don't call a setter for this property (e.g. it might even be a readonly property), any other call to the parent might cause it to release the previous returned object. So I always would have to retain any object I received through any method call you can think of before using it. Even if I just want to pass it on I have to retain it:

	id value = [someObject value];
	[value retain];
	[someOtherObject setValue:value];
	[value release];

Why? How can I know that someOtherObject won't have a reference to someObject and that calling setValue of someOtherObject won't make a call to someObject which causes some object to release the value it returned before, without someOtherObject having a chance to retain it? Since someOtherObject cannot know from where it received the value and it certainly won't expect this value to "go away" just because it calls some method of someObject. Does that make any sense? If not, maybe with some more code. Assume that my code is only like that:

	[someOtherObject setValue:[someObject value]];

Pretty typical code you find in millions of source files. However, now consider someOtherObject has a reference to someObject and part of their implementation will look like this:

// someObject

	- (id)value
	{
		return value;
	}

	- (void)doSomething
	{
		// ...
		[value release];
		value = ...;
		/ /...
	}

// someOtherObject

	- (void)setValue:(id)aValue
	{
		[someObject doSomething];
		if (value == aValue) return;

		[value release];
		value = [aValue retain]; // <--- BANG, CRASH
	}

So I would have in fact to always retain any value before doing anything with it, even when I just want to pass it on! Think about it.

Kind regards,
Markus_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden

References: 
 >Re: Properties, Attributes and Retain+Autorelease (From: Matt Neuburg <email@hidden>)

  • Prev by Date: Re: Properties, Attributes and Retain+Autorelease
  • Next by Date: Re: Properties, Attributes and Retain+Autorelease
  • Previous by thread: Re: Properties, Attributes and Retain+Autorelease
  • Next by thread: Fuzzy string matching
  • Index(es):
    • Date
    • Thread