On Aug 25, 2014, at 11:12 AM, jahanian <[email protected]> wrote: > > On Aug 25, 2014, at 10:57 AM, Jean-Daniel Dupas <[email protected]> > wrote: > >> >> Le 25 août 2014 à 18:47, jahanian <[email protected]> a écrit : >> >>> >>> >>> On Aug 25, 2014, at 9:35 AM, jahanian <[email protected]> wrote: >>> >>>> >>>> On Aug 24, 2014, at 12:36 AM, Jean-Daniel Dupas <[email protected]> >>>> 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].” - Fariborz _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
