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. - Fariborz > My point is that even in +initialize implementation, that method should never > be called directly. > > When the runtime load a class, it will first load all parents classes, and > call +initialize on each class. > > For instance, if we have a class Foo, a class A that inherits Foo and a class > B that inherits A, with each class implementing +initialize. > > The first time trying to access B, the runtime calls [Foo initialize], then > it calls [A initialize], and finally it calls [B initialize], so there is no > reason that one of these classes should call the super implementation. > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
