NSError returned by WebKit API should actually conform to NSSecureCoding
Created attachment 421037 [details] Patch
<rdar://problem/63893583>
Comment on attachment 421037 [details] Patch r=me.
Committed r273181: <https://commits.webkit.org/r273181> All reviewed patches have been landed. Closing bug and clearing flags on attachment 421037 [details].
Comment on attachment 421037 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=421037&action=review > Source/WebKit/UIProcess/Cocoa/WKReloadFrameErrorRecoveryAttempter.mm:80 > + return [super init]; What is the advantage of calling [super init] here rather than [self init]?
In this case, I think they are equivalent. I count 16 calls of [self init] and 464 calls of [super init] in WebKit.
(In reply to Alex Christensen from comment #6) > In this case, I think they are equivalent. I count 16 calls of [self init] > and 464 calls of [super init] in WebKit. I think there are two differences: 1) Calling [super init] calls the init method in the superclass. If the class itself has an init method, it’s ignored, and if the class supports subclassing, the subclass's init method is ignored. 2) Calling [self init] is slightly faster?
Typically we only call [super init] in implementations of init methods that do *not* want to call the init in this class.
The pattern I'm familiar with is this: if (!(self = [super init])) return nil; // Initialize all the things in self that are specific to this subclass return self; In this case there is nothing special to initialize in this subclass because all members are default-initialized C++ classes, so I want to return the result of [super init] without doing anything additional to self. I still think in this case the two are equivalent.