Swift Programming Language's example code does not call super.init in the first line. It would seem that's an unsafe practice as an inherited item can be overridden by parent constructor, right?
class EquilateralTriangle: NamedShape {
var sideLength: Double = 0.0
init(sideLength: Double, name: String) {
self.sideLength = sideLength
super.init(name: name)
numberOfSides = 3
}
var perimeter: Double {
get {
return 3.0 * sideLength
}
set {
sideLength = newValue / 3.0
}
}
override func simpleDescription() -> String {
return "An equilateral triagle with sides of length \(sideLength)."
}
}
In initializers you have to fully prepare the object before calling super.init(). That means that all properties declared by the subclass need to have a value by the time you call the super implementation of the initializer.
After calling super.init() you may overwrite properties inherited from the superclass. numberOfSides is an inherited property and because of that it's overwritten after calling the super implementation.
numberOfSides = and self.numberOfSides = are equivalent in this example.
To put things short:
1. Properties declared by the subclass must be set before calling super.init()
2. Inherited properties must be overwritten after calling super.init()
The compiler will throw an error for the first case, but I'm not sure about the latter.
Related
I am taking an online class on swift and an example was shown. Why is self used with the init method call but not on colour?
class Car {
var colour = "Black"
var numberOfSeats = 5
var typeOfCar : CarType = .Coupe
init() {
}
convenience init (customerChosenColour : String) {
self.init()
colour = customerChosenColour
}
}
An init() runs when someone makes a new instance of that class like this:
var newInstanceOfCar = Car()
A convenience init allows you to create other initializers for certain use cases, like when there is a customerChosenColour that needs to be specified. It makes things more convenient in those cases.
The reason why self is used, is because when you create convenience init, you still need to call the "main" init, which is a property of self.
You can use self on colour, but it isn't necessary. You would use self.colour, if colour was ambiguous, like in this example:
class Car {
var colour = "Black"
var numberOfSeats = 5
var typeOfCar : CarType = .Coupe
init() {
}
convenience init (colour : String) {
self.init()
self.colour = colour
}
}
Notice how colour is a property of Car, but is also the name of the parameter for the convenience init. It would be confusing to write colour = colour.
So we use self to say that we want the variable in our class, self.colour, to be equal to the value of the parameter, colour.
As you wonder why self. cannot be omitted in self.init(), you can think of self.init() as whole is a special keyword just for convenience initializer. Same as super.init() as whole is a special keyword just for designated initializer. And Car.init()aka Car() is for creating a new instance. Calling init() itself without any receiver is not a valid call ever. So you can treat function call init() as nonexistence, self.init() is one keyword, super.init() is another keyword.
init() is not a member function, it is the initializer, some special code which will be run when creating new instances of that class. Don't treat initializers as regular member functions. They don't have the func keyword in front. They don't have the property of member functions. You can call member function on an instance but you cannot call initializer on an instance (Car().init() is not valid). self.init() dose NOT mean calling a function named init() from self.
class Foo
{
init(){}
func foo(){}
func bar()
{
self.foo() //valid. regular member function call
self.init() //invalid. init() is not a member function of the instance
}
}
Don't think self.init() like calling regular method from the same class, where self. can be omitted, but rather treat the whole thing as a special keyword that means "initialize this object with the designated initializer first".
I would like to do something similar to the following with an NSObject subclass
class Thing: NSObject {
class func defaultText() -> String { ... }
let text: String
init(text: String?) {
self.text = text ?? self.dynamicType.defaultText() // Of course, this line won't compile
super.init()
}
}
so that Thing subclasses may override defaultText() without requiring them to override the initializer. This is easy to do with a mutable stored property, but it would be nice to have it constant. Is there a way to do this?
This is a separate issue than overriding static vars in subclasses swift 1.2 . There is no desire to override a constant or a static method. The only thing in question is, in the initializer where the constant is set, is there a way to compute a value based on the specific class that is being initialized?
I have a superclass where a vector is being created as a member variable.
class GameScene: SKScene, SKPhysicsContactDelegate {
var floatingBlockPositions: [CGPoint] = [CGPointMake(130.0, 70.0)]
}
I am overriding it in a subclass like so:
class StreetFight: GameScene {
override var floatingBlockPositions: [CGPoint] {
get {
return [CGPointMake(400.0, 70.0), CGPointMake(250.0, 95.0)]
}
set (newValue) {
newValue
}
}
}
I have a class method that mutates it to set another parameter.
temp = 0
for _ in floatingBlockPositions {
floatingBlockPositions[temp].y = floatingBlockPositions[temp].y + positionsForFirstBlock.y + (groundBlockSize.height / 2)
let aerialBlock = SKSpriteNode(imageNamed: "aerialBlock")
aerialBlock.position = floatingBlockPositions[temp]
temp++
}
After debugging, I see that the setter in the subclass is being called, but it is not being set properly because the equals operator in the function is trying to set only one part of one of the CGPoints in the vector, which the setter is not set up to handle, no pun intended. How can I write the setter in the subclass so it recognizes what part of floatingBlockPositions needs to be set and sets it. If possible, should I overload the method, or is there a better way to do it?
You've changed floatingBlockPositions from a stored property to a computed variable (because it has a get). Therefore, you cannot store a new value for it. However, you can create a separate private var and set that, and then in get, if that is set, return that new value.
Here is my code:
class Base
{
init(){
print("Super!")
}
}
class Test : Base
{
internal var y:Int
convenience init(_ a:Int)
{
self.init()
print("\(a)")
}
override init()
{
super.init() //Error!!! Property 'self.y' not initialized at super.init call
y = 123
}
}
I think this should be compiled:
y is not visible inside class 'Base',whether order of initializations of y's and super class's doesn't really matter.
Your argument
I think this should be compiled:
y is not visible inside class 'Base',whether order of initializations
of y's and super class's doesn't really matter.
is not correct, that would not be safe.
The superclass init can call an instance
method which is overridden in the subclass. That is (at least one)
reason why all subclass properties must be initialized before super.init() is called.
A simple example:
class Base
{
init(){
print("enter Base.init")
setup()
print("leave Base.init")
}
func setup() {
print("Base.setup called")
}
}
class Test : Base
{
internal var y:Int
override init()
{
y = 123
print("before super.init")
super.init()
print("after super.init")
}
override func setup() {
print("Test.setup called")
print("y = \(y)")
}
}
Output:
before super.init
enter Base.init
Test.setup called
y = 123
leave Base.init
after super.init
As you can see, the y property of the subclass is accessed
during the super.init() call, even if it is not known to the
superclass.
It might be interesting to compare the situation in Objective-C
where self = [super initXXX] is always called first. This has the
consequence that property access self.prop in init/dealloc methods
is unsafe and direct access to the instance variable _prop is
recommended because the object may be in a "partially constructed state".
See for example Should I refer to self.property in the init method with ARC?.
So this is one of the issues which have been solved in Swift
(at the cost of stricter requirements).
From the documentation:
Safety check 1
A designated initializer must ensure that all of the
properties introduced by its class are initialized before it delegates
up to a superclass initializer.
As mentioned above, the memory for an object is only considered fully
initialized once the initial state of all of its stored properties is
known. In order for this rule to be satisfied, a designated
initializer must make sure that all its own properties are initialized
before it hands off up the chain.
Source: Swift Language Guide: Initialization
Just exchange the two lines in init
override init()
{
y = 123
super.init()
}
I have two properties in my class. See this terrible example:
var length
var doubleLength
How do I initialize doubleLength based on length?
init() {
self.length = ...
self.doubleLength = self.length * 2
super.init()
}
I get an error that I can't access self before I call super.init(). Well I need to set all my variables before I can even call super.init() so what am I supposed to do?
if self.doubleLength is always supposed to be twice self.length (in this example) have you considered just using a computed property?
class MyClass: MySuperClass {
var length: Double
var doubleLength: Double {
return self.length * 2
}
init(len: Double) {
self.length = len
super.init()
}
}
You can temporarily delay the initialization of doubleLength an implicitly unwrapped optional, which will allow to temporarily assign a value to nil and assign it at a later time.
class Something: UICollectionViewLayout {
var doubleLength: Int! = nil
var length: Int {
return 50
}
init() {
super.init()
doubleLength = length * 2
}
}
Anyway, in this specific case I think it would be nicer to make doubleLength a computed property, since it can be always be computed from the value of length. Your class will be like
class Something: UICollectionViewLayout {
var doubleLength: Int {
return length * 2
}
var length: Int {
return 50
}
}
Thanks for your full reproduction, which is:
import UIKit
class Something: UICollectionViewLayout {
var doubleLength: Int
var length: Int {
return 50
}
init() {
doubleLength = length * 2
super.init()
}
}
From this we can see that you're using a getter to return your property. I think this is what's causing the problem. For example, if you just do this:
import UIKit
class Something: UICollectionViewLayout {
var doubleLength: Int
// Simple variable, no code.
var length = 50
init() {
doubleLength = length * 2
super.init()
}
}
...then that works fine.
I believe this is because the Swift compiler is trying to prevent you from doing anything that might mean you use the base class's methods, properties or variables before it's been initialised. I know you're technically not, in your example, but consider how hard it is to trace back and see what's being done from your initialiser. For example, if you were to do:
var length: Int {
// Where "width" is a made-up property of UICollectionViewLayout
return width * 3
}
...then your code would be run from your initialiser and use a property of UICollectionViewLayout before its own init had been called, therefore making it possibly invalid.
So my best guess is that this is the Swift compiler making a blanket ban on calling out to any code outside the subclass initialiser before the super is initialised.
You get exactly the same error if you do this, for example:
class Something: UICollectionViewLayout {
func foo() {
// Do nothing
}
init() {
foo() // error: 'self' used before super.init call
super.init()
}
}
The place I remember this being explained is the "Intermediate Swift" video from WWDC 2014, from slide 191, about 20 minutes in, but I'm guessing it's somewhere in the book, too...
A property that depends on another is bad practice. Just like when you design a database, you avoid calculated fields, when you design classes, you also avoid calculated fields. Instead of having a doubleLength property, you should instead have a getDoubleLength method that returns the length * 2.