[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 10 Jun 2011 14:14:07 +0100
On 2 Jun 2011, at 10:40, David Chisnall wrote:
> On 2 Jun 2011, at 06:28, Richard Frith-Macdonald wrote:
>> On 1 Jun 2011, at 23:48, David Chisnall wrote:
>>> This is actually wrong in retain / release mode (-retain is not guaranteed
>>> to return self),
>> The guarantee is that it's specifically documented to do so in the protocol
>> .... see
>> So any implementation of -retain which doesn't return self is faulty, and
>> the programmer really deserves any error they have introduced by
>> overriding/replacing the default one.
> My reading of that is that the requirement to return self is only a
> requirement for objects implementing their own reference counting.
I guess that's a possible reading (though it certainly doesn't say that) ...
but hard to justify I think. The NSObject class adopts/conforms to the
NSObject protocol and Apple don't document an alternative behavior afaik, so
really it (and anything based on it) should do what the protocol says. It
seems to me that your reading assumes that documented behaviors are telling you
what to do when you override a method rather than telling you what a method
does which, while a possible point of view, is pretty much unique to you I
think. In my experience, whenever documentation is telling you what to do when
you override something, it makes a clear distinction between default behavior
and the overridden behavior.
> The more formal description of -retain in the static analyser expects -retain
> to return an owning reference, but not necessarily to the same object as the
I think you must have misread ... the clang static analyser agrees with me:
c = [c retain];
produces the warning
'Assigned value is always the same as the existing value'
- GSIMap, David Chisnall, 2011/06/01