Re: [PATCH] Fix NSMenu retainCount problem

[Alexander Malmberg]

Quentin Mathé wrote:
> the user shouldn't have to know the framework implementation. In other
> terms, correct objective-c memory management needs to support this rule
> : sending a message to an object should never induce increased retain
> count for this object.

I don't think this rule should be adopted. It's blatantly false for a
huge number of methods. While I can see that it would be useful in some
odd cases, the huge number of exceptions would make it difficult to rely
on. Cascading exceptions would make things even worse. For example, note
that methods implemented like:

-(NSString *) uppercaseString
{
        if (!self_contains_lowercase_characters)
                return [[self copy] autorelease];
        else
        {
                /* create new string, etc. */
        }
}

violate this rule and would have to rewritten in a less clear and less
efficient way.

The library should be free to autorelease objects. Library methods
should use their own autorelease pools if they autorelease a "large"
number of objects, and must always use one if the number of autoreleased
objects is unbounded. However, in the end, when the method returns, the
number of autoreleases on the objects that have been involved is
unspecified.

If you're relying on exactly when -dealloc is called for an instance
(which should be very rare), you need to explicitly manage autorelease
pools to ensure that there are no pending autoreleases. Alternatively,
you can split out the necessary "invalidation" from the -dealloc (like
eg. -base's NSConnection).

- Alexander Malmberg