�ݺ�ߣ

let swiftInitialzersTalk = Talk(for lang: )
FORWARD SWIFT 16 | BY @JORDANMORGAN10

WHO AM I?
IOS DEV @
▸ iOS dev since iOS 6
▸ Talks, blog, online courses, etc.

FORWARD SWIFT 16: SWIFT INITIALIZERS
WHY TALK ABOUT SWIFT’S INITIALIZERS?
▸ A common point of friction
▸ …there is no escaping them
let foo = Box()

OBJECTIVE-C INIT
- (instancetype)init
{
self = [super init];
if (self)
{
//Setup code...
}
return self;
}

TRYING THAT IN SWIFT…😱
class Foo
{
init()
{
self = super.init()
if self
{
}
return self
}
}

OBJECTIVE-C INITS != SWIFT INITS
Why?

SWIFT’S DESIGN GOALS
▸ SAFE
▸ FAST
▸ EXPRESSIVE

▸ SAFE
▸ FAST
▸ EXPRESSIVE
SAFE
EXPRESSIVE

OPTING FOR SAFETY SOMETIMES MEANS SWIFT WILL FEEL
STRICT, BUT WE BELIEVE THAT CLARITY SAVES TIME IN THE
LONG RUN.
SAFE
EXPRESSIVESWIFT BENEFITS FROM DECADES
OF ADVANCEMENT IN COMPUTER
SCIENCE TO OFFER SYNTAX THAT
IS A JOY TO USE, WITH MODERN
FEATURES DEVELOPERS EXPECT.

THE MOST BASIC SWIFT INIT: TAKE TWO
class Foo
{
init()
{
self = super.init()
if self
{
}
return self
}
}
class Foo
{
init()
{
}
}
class Foo
{
}
let aFoo = Foo()

▸ Phase One
▸ Init() is called
▸ Memory allocated
▸ Each of the instance stored props gets a value
▸ Memory is fully initialized
▸ Init() delegation kicks in - does the same thing
▸ Instance methods or self are not allowed here
TWO PHASE INITIALIZATION
class Foo { }
let aFoo = Foo()
Memory

▸ Phase Two
▸ Each Init() can customize the instance further
▸ Self is allowed, instance methods can be called
▸ …but they deﬁnitely don’t have to
TWO PHASE INITIALIZATION
class Foo { }
let aFoo = Foo()
Memory

BUT WAIT…THERE’S MORE!
class Foo
{
init() {}
}
class Foo
{
required init() {}
}
class Foo
{
convenience init() {}
}
class Foo
{
init?()
}
struct Foo
{
init() {}
}

KEY POINTS TO REMEMBER WITH SWIFT INITIALIZERS
▸ Swift inits vs Objective-C inits are very different
▸ More thought comes into play with inheritance
▸ It’s largely driven by deﬁnitive initialization
▸ …which means, all properties need a value!
Swift properties cannot be in an indeterminate
state before the instance is used

▸ This won’t compile - why?
WORKING WITH STRUCTS
struct ConferenceTalk
{
var talkName:String
init() { }
}

▸ This won’t compile - why?
{
var talkName:String?
init() { }
}
{
var talkName:String
init() { }
}
This becomes the designated initializer for ConferenceTalk

{
var talkName:String?
init() { }
}
{
var talkName = ""
init() { }
}
{
var talkName:String
init() { self.talkName = "" }
}
{
var talkName = { /*...*/ return ""}()
init() { }
}

{
var presenter:String?
var talkName = {
self.presenter = "Something"
return ""
}()
init() { }
}
{
var talkName = { /*...*/ return ""}()
init() { }
}
Compilation Error!

▸ Ties a property’s init closely to its declaration
▸ Intent is clear
▸ Initializers inheritance
▸ Type inference!
▸ …default init() for free
//Use defaults 👍
{
var talkDuration = 0.0
}
WORKING WITH STRUCTS - USE DEFAULT VALUES

▸ What about when defaults don’t make sense?
{
var speakerName:String
var topics:[String]
}

▸ Memberwise Initializers 👏
▸ No default values? No prob! *
▸ Custom inits() wipe this out
{
var topics:[String]
}
let fsTalk = ConferenceTalk(talkDuration: 45,
speakerName: "Jordan",
topics: ["Swift", "Inits"])

▸ …but don’t wanna lose my free one!
▸ Extensions allow this
▸ Only convenience inits() though
WORKING WITH STRUCTS - WAIT, I WANT A CUSTOM INIT()
extension ConferenceTalk
{
//An init
}

WORKING WITH STRUCTS - WAIT, I WANT A CUSTOM INIT()
extension ConferenceTalk
{
init(jordansTalk duration:Double)
{
self.init(talkDuration:duration,
speakerName:"Jordan",
topics:["Swift", "Inits"])
}
}
let myTalk = ConferenceTalk(jordansTalk: 45)

WORKING WITH CLASSES A.K.A. HARD MODE
▸ …not really, but there is more to think about 🤔
Swift properties cannot be in an indeterminate
state before the instance is used
- and -
Any instance must have ﬁrst dibs on setting any
properties that it introduced

DESIGNATED INITIALIZERS - EVERY CLASS NEEDS ONE
▸ Eventually, every instance gets initialized from a designated init()
▸ Enforces that each property introduced by that class has a value
▸ Then it calls an initializer from its superclass
class ConferenceTalk
{
init(speaker:String)
{
self.speakerName = speaker
}
}
let conTalk = ConferenceTalk(speaker: "Jordan")

DESIGNATED INITIALIZERS CONT.
▸ Think of them as a “funnel”
▸ Typically, each class only has one of these
public init(nibName nibNameOrNil: String?, bundle nibBundleOrNil: Bundle?)

CONVENIENCE INITIALIZERS - HELPFUL BUT NOT REQUIRED
▸ Supporting, helpful initializers
▸ Great for speciﬁc use cases
▸ They’ll eventually hit a designated initializer

CONVENIENCE INITIALIZERS - EXAMPLE
{
{
}
convenience init()
{
self.init(speaker:"Unknown")
}
}
let unknownTalk = ConferenceTalk() //unknownTalk.speakerName == "Unknown"

CONVENIENCE INITIALIZERS - HELPFUL/NOT REQUIRED
{
}
convenience init()
{
}
let unknownTalk = ConferenceTalk()

LAWS OF THE LAND
▸ Rule 1
▸ A designated initializer must call a designated initializer
from its immediate superclass.
class ForwardSwiftTalk : ConferenceTalk
{
let talkLocation:String
init(location:String)
{
self.talkLocation = location
super.init(speaker: "")
}
}

LAWS OF THE LAND
▸ Rule 2
▸ A convenience initializer must call another initializer
from the same class.
{
{
}
convenience init()
{
self.init(location: "Hall A")
}
}

LAWS OF THE LAND
▸ Rule 3
▸ A convenience initializer must ultimately call a
designated initializer.
{
{
}
convenience init()
{
}
}

THE EASY WAY TO REMEMBER THIS?
Designated Initializers delegate up
Convenience Initializers delegate across

WHAT HAPPENS WHEN I SUBCLASS?
{
{
}
convenience init()
{
}
}
{
//Now Wut 😐???
}

INHERITANCE
▸ Unlike Objective-C - you don’t always get super’s inits()
▸ But if:
▸ The subclass doesn’t have any custom inits() then 👌
▸ If you have an implementation of all of super’s designated inits
either from rule 1 or by a custom implementation - then you get
convenience inits() too!
let fsTalk = ForwardSwiftTalk()

INHERITANCE IN ACTION
{
{
}
convenience init()
{
}
}
{
{
}
}
let fsTalk = ForwardSwiftTalk(location: "Hall A")

{
}
{
}

SUBCLASS CONVENIENCE HAVE THE SAME RULES
{
{
}
convenience init()
{
}
}
let fsTalk = ForwardSwiftTalk()

▸ Each class is responsible for setting initial values for things
that it introduces!
THE TRICK REALLY IS TO REMEMBER THAT…
{
{
}
}
{
{
}
}
👍 🙅

▸ Why? Because super’s designated init() had the chance to
set them before anyone else did (i.e. FowardSwiftTalk)
AFTER THAT POINT - YOU CAN CUSTOMIZE SUPER’S PROPS
{
{
self.speakerName = "¯_( )_/¯"
}
}
FYI: This is crazy town if you’re still wearing Objective-C glasses

▸ Failable inits() allow for you to say “This might not work”
▸ Most famously…
▸ Here, we’ve got an optional UIImage instance
ENOUGH ABOUT INHERITANCE - LET’S TALK FAILURE
let maybeAnImage = UIImage(named: "Jordan_Excercising")

FAILABLE INITIALIZERS EXAMPLE
{
init?(speaker:String)
{
if speaker.isEmpty
{
return nil
}
}
}
let emptyTalk = ConferenceTalk(speaker: "")
if let aTalk = emptyTalk
{
//We've got something
}

FAILABLE INITIALIZERS ARE QUITE FANCY, BECAUSE
They can delegate up
and across
to one of super’s failable initializers
to another failable initializer within the instance

FLEXIBLE: OVERRIDE A FAILABLE WITH A NON-FAILABLE
{
var speakerName:String?
init(){}
{
if speaker.isEmpty
{
return nil
}
}
}
{
override init()
{
self.talkLocation = ""
super.init()
self.speakerName = "No Speaker Set"
}
override init(speaker:String)
{
self.talkLocation = ""
super.init()
self.speakerName = speaker.isEmpty ? "No
Speaker Set" : speaker
}
}

YOU CAN TRIGGER A FAILURE ANYTIME
{
{
if speaker.isEmpty
{
return nil
}
}
}
{
init?(location:String, speaker:String)
{
if location.isEmpty
{
return nil
}
super.init(speaker: speaker)
}
}

LASTLY, LET’S TALK REQUIRED INITIALIZERS
▸ Use these to signify that subclasses must implement it
{
required init(speaker:String)
{
}
}
{
{
}
}
Compilation Error!

ISSUES WITH SUBCLASSING UIVIEWCONTROLLER? THIS IS WHY.
class FooViewController:UIViewController
{
let aValue:String
init(someValue:String)
{
self.aValue = someValue
super.init(nibName: "", bundle: nil)
}
}

ISSUES WITH SUBCLASSING UIVIEWCONTROLLER? THIS IS WHY.
{
let aValue:String
{
}
}
{
let aValue:String
{
}
required init?(coder aDecoder: NSCoder)
{
self.aValue = ""
super.init(coder: aDecoder)
}
}

WRAP UP: TO MAKE THINGS EASY JUST REMEMBER THAT
▸ Always start with making sure your properties have a value
before anything else
▸ An instance always has ﬁrsties on setting its introduced
instances. So when inheriting, call super’s init before you try and
set its properties
▸ Look out for required inits (i.e. UIViewController)
▸ Value types are easier (no inheritance to worry about)
▸ Don’t think about Objective-C inits at all when writing Swift
ones

THE PLUGS
▸ @jordanmorgan10 on the Twittersphere
▸ bit.ly/iosdevguide - Also pluralsight.com for iOS courses.
▸ @bufferdevs | overﬂow.buffer.com | github for open source

bit.ly/bfrimgviewer bit.ly/bfrgifrefresh bit.ly/bfrswiftkit

let restOfFS16 = FSCon(be super:.Awesome)
👋

�ݺ�ߣ

Swift initcopy

Recommended

More Related Content

Similar to Swift initcopy (20)

Recently uploaded (20)

Swift initcopy