r216282 - Objective-C. Update my previous patch to not warn if

[Jean-Daniel Dupas]

Le 25 août 2014 à 22:58, jahanian <fjahanian at apple.com> a écrit :

> 
> 
> On Aug 25, 2014, at 11:12 AM, jahanian <fjahanian at apple.com> wrote:
> 
>> 
>> On Aug 25, 2014, at 10:57 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote:
>> 
>>> 
>>> Le 25 août 2014 à 18:47, jahanian <fjahanian at apple.com> a écrit :
>>> 
>>>> 
>>>> 
>>>> On Aug 25, 2014, at 9:35 AM, jahanian <fjahanian at apple.com> wrote:
>>>> 
>>>>> 
>>>>> On Aug 24, 2014, at 12:36 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote:
>>>>> 
>>>>>> Are you sure excluding that case is right ?
>>>>>> 
>>>>>> AFAIK, call [super initialize] is suspicious, as the runtime already call it for each class in the hierarchy.
>>>>> [super initialize] is called from inside +initialize implementations.
>>>>> So, we don’t want to warn.
>>>> 
>>>> I guess, I can restrict this to not warn if it is inside +initialize implementation and warn in other situations.
>>>> 
>>> 
>> 
>> Makes sense to me. Thanks for clarification. I cc our runtime folk who suggested the ‘super’ thing.
>> I am wondering if there are other scenarios of initialization that Greg has in mind.
> 
> And here is Greg’s scenario:
> "Sometimes a superclass expects to see the +initialize call on behalf of each of its subclasses. (For example, the superclass wants to maintain a registry of subclasses in use, without requiring each subclass to manually call some registration method.) If a subclass of such a class wants to implement +initialize itself, it must call [super initialize].”
> 

Thanks for the clarification. I still think this is a fragile scenario as any class that implements +initialize will have to call super implementation which is not the usual pattern.

As calling [super initialize] is guarantee to be harmless (all classes must be prepared to receive multiple initialize call), silencing that warning should not cause any issue, so if it is helpful for some cases, then it is OK to do it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140826/3d03dc2d/attachment.html>