69: Episode 69 - This Should Have Been a Point Release
May 20, 2015 at 12:30PM •
9 minutes •
Darryl finishes up some homework assignments and address some corrections. He covers Overriding private methods, private methods in notification selectors, factory methods and follow-up on initializers.
Show Notes & Links
Presented by CacheFly
Override of private methods:
Descendant methods with the same signature as an ancestor’s private method are not considered overrides:
- Only methods that are visible to a given class can be overridden.
- When the ancestor class makes a call to the private method, the ancestor’s method is indeed called, not the non-overridden method in the descendant class.
- Descendants can override methods that are visible to them and promote their visibility (even implicitly: Make sure you explicitly specify private if you want to keep something private.)
Use of private methods in notification selectors:
- Classes need to descend from NSObject (or at least implement all the expected methods used for invocation, etc)
- Using private methods as notification handlers results in a crash: unrecognized selector
- Because the methods used in notifications must be visible, the descendant’s implementation is what will be invoked, and it will clearly be an override. This does help the case we discussed in episode 68.
Argument order of member-wise struct initializers:
The order does appear to be the order in which the properties are declared.
Convenience initializers really do replace the factory methods found in Objective-c classes. Take a look at the Swift bridge for NSString as an example. There are two designated initializers and a whole slew of convenience initializers, but no class methods bridging the ones found in Objective-c.
Failable initializers: init? vs init!
- For value types, failable initializers can fail at any point during the initialization process, but class types can only fail once all properties have been initialized and initializer delegation has taken place. You can work around this using implicitly unwrapped optionals, but this seems strange to me.
- I’m still confused by init!. I’ve tested this out, and I do get an implicitly unwrapped optional. If I assign this to a non-optional variable and initialization did fail, I get a “unexpectedly found nil while unwrapping an Optional value” exception, as I would expect. But what is the benefit of an implicitly unwrapped failable initializer? If you’re confident that it’s safe to implicitly unwrap the optional, why make it failable at all? Wouldn’t it always be safer to use a regular failable initializer and require consumers to perform checks?
Inout parameters during initialization:
This is indeed possible. When bridging with Objective-c, however, an NSErrorPointer is used, which is an AutoreleasingUnsafeMutablePointer of an NSError optional. I still think it would’ve been nice if Swift used tuples for failable initializers, but since we can’t do that, should we adopt the convention of using inouts?
Alternative Show Titles
- Darryl Does His Homework
- You Call That An Episode?!?!
- var episode69 : Episode?