I'm using XLForm, which has a class XLFormDescriptor, which needs to be initialized with init(title: String).
The title I want to use is the return value of my current class's name function (class-level properties aren't a feature yet).
Putting this at a class level, the code to set it up looks like this:
let settingsForm = XLFormDescriptor(title: self.name())
But this gives the error:
'PanelController -> () -> PanelController!' does not have a member
named 'name'
Putting this at the top of the class's init call looks like this:
let settingsForm: XLFormDescriptor
override init() {
self.settingsForm = XLFormDescriptor(title: self.dynamicType.name())
super.init()
}
And doing that gives this error:
'self' used before super.init call
Putting it after super.init() gives this error:
Property 'settingsForm' not initialized at super.init call
Any ideas how I can possibly do this?
EDIT: A workaround is to do this:
let settingsForm = XLFormDescriptor(title: "")
override init() {
super.init()
self.settingsForm = XLFormDescriptor(title: self.dynamicType.name())
}
In swift, self is not available until all class properties have been initialized. There's a check at compilation time for that.
So if you have a class with properties, inherited from another class:
class A {
var prop1: Int
init(val1: Int) {
self.prop1 = val1
}
}
class B : A {
var prop2: String
override int(val1: Int, val2: String) {
// First initialize properties of this class
self.prop2 = val2
// Next call a superclass initializer
super.init(val1: val1)
// From now on, you can use 'self'
}
}
you cannot use self until all (non optional) class properties have been been initialized and a superclass initializer has been invoked (if the class is inherited).
If you initialize a property inline, like this:
let settingsForm = XLFormDescriptor(title: self.name())
you are explicitly using self before the class instance has been properly initialized - that's the reason of the compilation error.
The solution you found yourself is not a workaround, but the right way of doing it. You first initialize the property with a value not referencing self, then once the class has been initialized, you assign that property a new value.
Note that this is the only case where you are allowed to assign a new value to an immutable property, as long as it is done from within an initializer.
For a better understanding of how initialization works, I recommend reading the corresponding documentation: Initialization
Related
I have a simple class and I want to use keypath in the init, something like this:
class V: UIView {
convenience init() {
self.init(frame: .zero)
self[keyPath: \.alpha] = 0.5
}
}
let v = View()
When I run this code I get a runtime error:
Fatal error: could not demangle keypath type from ' ����XD':
But, if I specify the type in keyPath it works fine:
class V: UIView {
convenience init() {
self.init(frame: .zero)
self[keyPath: \UIView.alpha] = 0.5
}
}
let v = View()
print(v.alpha) \\ prints 0.5
But, what's even stranger is that this code works:
class V: UIView {
convenience init() {
self.init(frame: .zero)
foo()
}
func foo() {
self[keyPath: \.alpha] = 0.5
}
}
let v = View()
print(v.alpha) \\ prints 0.5
What is the actual reason for this error?
Unsurprisingly, this is a compiler bug. In fact, it was reported only a couple weeks before you posted your question. The bug report contains a slightly simpler example that triggers the same crash:
class Foo: NSObject {
#objc let value: String = "test"
func test() {
let k1 = \Foo.value // Ok
let k2 = \Self.value // Fatal error: could not demangle keypath type from '�: file /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/swiftlang/swiftlang-1103.8.25.8/swift/stdlib/public/core/KeyPath.swift, line 2623
}
}
Foo().test()
It turns out the Swift compiler was not properly handling key paths containing the covariant Self type. In case you need a refresher, the covariant Self type or dynamic Self type allows you to specify that a method or property always returns the type of self even if the class is subclassed. For example:
class Foo {
var invariant: Foo { return self }
var covariant: Self { return self }
}
class Bar: Foo {}
let a = Bar().invariant // a has compile-time type Foo
let b = Bar().covariant // b has compile-time type Bar
func walkInto(bar: Bar) {}
walkInto(bar: a) // error: cannot convert value of type 'Foo' to expected argument type 'Bar'
walkInto(bar: b) // works
But your example doesn't use dynamic Self! Well actually it does: in the context of a convenience initializer, the type of self is actually the dynamic Self type, because a convenience initializer can also be called to initialize a subclass of your class V.
So what exactly went wrong? Well, the Swift compiler did not include any logic to handle dynamic Self when creating a key path. Under-the-hood, it essentially tried to emit a key path object of type ReferenceWritableKeyPath<Self, CGFloat>. The type system doesn't allow you to use dynamic Self in that context, and the runtime was not expecting it. The strange error message you received was the result of trying to decode this unexpected object type, which was encoded as a 4-byte relative pointer to the metadata for your V class, followed by the suffix XD indicating a dynamic Self type (hence the error message containing 4 �'s followed by XD). By playing around with different ways to create key paths involving dynamic Self, I came across a number of different crashes at both compile-time and runtime.
I have submitted a fix for this bug. It turned out to be pretty simple: essentially, everywhere we find a dynamic Self when creating a key path, we just replace it with the static self and add downcasts when necessary. Dynamic Self only matters to enforce program correctness at compile time; it can and should be stripped out of the program before runtime.
It is because of convenience init(), Convenience initializers are secondary, supporting initializers for a class. You can define a convenience initializer to call a designated initializer from the same class as the convenience initializer with some of the designated initializer’s parameters set to default values.
Since, in convenience init() the super class property can't be accessed, you are getting Fatal error: could not demangle keypath type.
If you do the same in the designated init() it will work as it is sure that super class is initialized. Below code will print 0.5 as expected:
class View: UIView {
init() {
super.init(frame: .zero)
self[keyPath: \.alpha] = 0.5
}
required init?(coder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
}
let v = View()
print(v.alpha) // prints 0.5
code running in xcode
“For computed type properties for class types, you can use the class keyword instead to allow subclasses to override the superclass’s implementation.”
“You can override an inherited instance or type property to provide your own custom getter and setter for that property”
----Apple Swift3
//override static
class A{
var myValue = 0614
static var storedTypeProperty = "Some value"
class var overrideableComputedTypeProperty: Int {
return 1
}
}
class B: A {
storedTypeProperty = "New String"
}
It seems like that B doesn't inherit any type property from A.
So how to override the "inherited type property" as described above in Swift3 book.
The problem you are facing is because you are using a static variable. static variables can not be overwritten, full stop. No point to argue here.
First sentence says, if you have a class (not a struct),like class A {} , you can use the class keyword instead of the static keyword, and override class types. This means, that you can use two keyword for the same purpose, with a major difference, that static can not be overwritten.
class A {
// overridable computed property
class var overridableClassPropery: String {
return "This is class A's overwritten property"
}
// Not overridable `static` computed property
// Error will be shown if you try to override this property in class `B`
static var notOverridableStaticPropery: String {
return "Can not override this property in a subclass"
}
}
The second one says, that you can override a superclasses class property, and provide your own get implementation in a subclass, like the following:
class B: A {
// Class type computed property can be overwritten
override class var overridableClassPropery: String {
return "This is class B's overwritten property"
}
}
EDIT:
notOverridableStaticPropery of class A is being inherited by class B, what means, you can access / call it through class B. BUT you can not override it, it will have the value set in class A always.
print(A.notOverridableStaticPropery) // prints "This is class A's not overridable static property"
print(B.notOverridableStaticPropery) // prints "This is class A's not overridable static property"
I am a beginner swifter and I'am facing a problem in my first application ...
I need to get a value from the class Person which is the userName value. I am going to display it in a label in the current view controller.
Here is what I have done so far.
This is the viewController where I am working in:
override func viewDidLoad() {
super.viewDidLoad()
var Name = Person().userName()
label.text = Name
}
And this is the class Person
class Person {
var cellName = "empty"
init(cellName : String) {
self.cellName = cellName
super.init()
}
func userName() -> String {
var uname = cellName
return uname
}
}
The userName() function will return the cellName, which will be initialised in another class.
The problem is in the viewDidLoad() function, I got an error which says "missing argument for parameter 'cellName' in call"
I have no idea what the solution of this problem is. I searched for similar errors but nothing works for me.
var Name = Person().userName()
Here, you're calling the initializer that you defined in your Person class, like this: init(cellName : String). However, you can clearly see that with these empty braces (), your call is indeed lacking the cellName argument.
Two solutions: either provide the cellName argument, or create another initializer that accepts no argument. Here's how it could look like:
init() {
super.init()
}
convenience init(cellName : String){
self.cellName = cellName
self.init()
}
EDIT: As a sidenote, from what I can see right now of your Person class, it could be a lot simpler. The userName doesn't have to be a func and could be a simple var. It is currently returning another existing var which is also public, so from what I can see right now, it is useless. In fact, you could actually rewrite the class with almost the same features using a single line of code, like this: struct Person { var userName = "empty" }. That's it :)
I am new to Swift and I'm wondering what self is used for and why.
I have seen it in classes and structures but I really don't find them essential nor necessary to even mention them in my code. What are they used for and why? In what situations it's necessary to use it?
I have been reading lots of questions and answers for this question but none of them fully answers my questions and they always tend to compare it with this as in Java, with which I'm not familiar whatsoever.
Yes it is the same as this in Java and self in Objective-C, but with Swift, self is only required when you call a property or method from a closure or to differentiate property names inside your code, such as initializers. So you can use almost all of your class components safely without using self unless you are making the call from a closure.
“The self Property Every instance of a type has an implicit property
called self, which is exactly equivalent to the instance itself. You
use the self property to refer to the current instance within its
own instance methods.
The increment() method in the example above could have been written
like this:
func increment() {
self.count += 1
}
In practice, you don’t need to write self in your code very often.
If you don’t explicitly write self, Swift assumes that you are
referring to a property or method of the current instance whenever you
use a known property or method name within a method. This assumption
is demonstrated by the use of count (rather than self.count)
inside the three instance methods for Counter.
The main exception to this rule occurs when a parameter name for an
instance method has the same name as a property of that instance. In
this situation, the parameter name takes precedence, and it becomes
necessary to refer to the property in a more qualified way. You use
the self property to distinguish between the parameter name and the
property name.
Here, self disambiguates between a method parameter called x and
an instance property that is also called x:”
Excerpt From: Apple Inc. “The Swift Programming Language (Swift 2 Prerelease).”
This is how Ray Wenderlich recommends the use of self in Swift for their tutorials:
Use of Self
For conciseness, avoid using self since Swift does not require it to access an object's properties or invoke its methods.
Use self when required to differentiate between property names and arguments in initializers, and when referencing properties in closure expressions as required by the compiler:
class BoardLocation {
let row: Int, column: Int
init(row: Int, column: Int) {
self.row = row
self.column = column
let closure = {
println(self.row)
}
}
}
And this is GitHub's recommendations on self for their applications:
Only explicitly refer to self when required
When accessing properties or methods on self, leave the reference to self implicit by default:
private class History {
var events: [Event]
func rewrite() {
events = []
}
}
Only include the explicit keyword when required by the language — for example, in a closure, or when parameter names conflict:
extension History {
init(events: [Event]) {
self.events = events
}
var whenVictorious: () -> () {
return {
self.rewrite()
}
}
}
Rationale: This makes the capturing semantics of self stand out more in closures, and avoids verbosity elsewhere.
You will also use self a lot when creating your extensions, example:
extension Int {
func square() -> Int {
return self * self
}
// note: when adding mutating in front of it we don't need to specify the return type
// and instead of "return " whatever
// we have to use "self = " whatever
mutating func squareMe() {
self = self * self
}
}
let x = 3
let y = x.square()
println(x) // 3
printlx(y) // 9
now let's say you want to change the var result itself
you have to use the mutating func to make change itself
var z = 3
println(z) // 3
now let's mutate it
z.squareMe()
println(z) // 9
// now let's see another example using strings :
extension String {
func x(times:Int) -> String {
var result = ""
if times > 0 {
for index in 1...times{
result += self
}
return result
}
return ""
}
// note: when adding mutating in front of it we don't need to specify the return type
// and instead of "return " whatever
// we have to use "self = " whatever
mutating func replicateMe(times:Int){
if times > 1 {
let myString = self
for index in 1...times-1{
self = self + myString
}
} else {
if times != 1 {
self = ""
}
}
}
}
var myString1 = "Abc"
let myString2 = myString1.x(2)
println(myString1) // "Abc"
println(myString2) // "AbcAbc"
now let's change myString1
myString1.replicateMe(3)
println(myString1) // "AbcAbcAbc"
In what situations it's necessary to use it
It is necessary to use it only when the name of a local variable overshadows the name of a property.
However, as a matter of style (and readability), I always use it:
I use it with property names, because otherwise I am left wondering what this variable is (since it is neither locally declared nor an incoming parameter).
I use it as the receiver of function (method) calls, in order to differentiate such methods from top-level or local functions.
This is why we need self.
When we define a class, like:
class MyClass {
func myMethod()
}
We are creating a "Class Object". Yes, Class is an object too.
Then no matter how many instances are created using the class, all instances will have a reference pointer to its Class Object.
You can imagine that all instance methods defined by the Class are in the Class Object, and there will be only one copy of them.
That means all instances created using the Class are sharing the same method.
Now imagine you are the myMethod in the Class Object, and because you are shared for all instances, you must have a way to tell which instance you are working on.
When someone says instance1.myMethod(), it means "Hi! myMethod, please do your work and instance1 is the object you are working on".
To reference the object that the caller sent to you, use self.
“In practice, you don’t need to write self in your code very often. If
you don’t explicitly write self, Swift assumes that you are referring
to a property or method of the current instance whenever you use a
known property or method name within a method.”
Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks.
https://itun.es/tw/jEUH0.l
The reserved word self in Swift is similar to this but it's not the same as in Java or JavaScript.
As #Dave Gomez correctly quoted:
Every instance of a type has an implicit property called self, which is exactly equivalent to the instance itself.
Here lies one of the main differences, because:
"Every instance" in Swift (at least for now) is almost every-thing.
In Java, for example, you can only use the word this inside an instance scope, in Swift you can use it almost every-where.
Here are a few examples:
//Example 1:
var x="foo"
x.self="bar".self//compiles and run
//Example 2:
print.self(x);//compiles and run
//Example 3:
func myOther(self otherSelf:Person){}
myOther(self: personObject);//compiles and run
//Example 4:
class Foo{
var bar=""
init(){
self.addSome()//this would be the same in Java
}
func addSome(){
//But definitely not this:
self.self.bar.self.self="some".self.self
}
}
//Guess what - also compiles and run...
let f=Foo()
print(f.bar)
See : Why 'self.self' compiles and run in swift for more information.
I arrived at this question while searching for self as a class function, which looks like this: Int.self, String.self, or YourClass.self
Previously, as near as I can tell, only Dmitri Pavlutin's answer touches on this, when he said:
When self is accessed in a type method (static func or class func), it refers to the actual type (rather than an instance).
When self is used this way, it actually returns what in Swift is called a Metatype. You can read the Swift documentation page on Types for more information.
There is also an article with more details about using and understanding metatypes called "What's .self, .Type and .Protocol? Understanding Swift Metatypes" on swiftrocks.com.
"How to use correctly 'self' keyword in Swift" explains self in detail.
self is a property on the instance that refers to itself. It's used to access class, structure and enumeration instance within methods.
When self is accessed in a type method like static func or class func, it refers to the actual type rather than an instance.
Swift allows omitting self when you want to access instances properties.
When a method parameter has the same name as an instance property, you have to explicitly use self.myVariable = myVariable to make a distinction.
Notice that method parameters have a priority over instance properties.
I'm a total noob at coding in general - and whilst these answers are great, from the perspective of a total noob who just wants it answered as practically as possible without all these difficult words and concepts, here's my Super Noob dumbed down version:
'self' is used because the coding application doesn't know which variable to use if you type the variable in the scope of your functions. It's all about the scope and making it clear which variable you're using if some other variable has the same name. Scope is the area inside the curly {} brackets. so for example:
{ scope1 {scope2} }
Here you don't need to use self:
class example {
private var exampleVar = “this is the class scope variable”
func x() {
//You don't have to use self here
print(exampleVar)
}
}
Here you do need to use self:
class example {
private var exampleVar = “this is the class scope variable”
func x(_ exampleVar: String) {
//It would be confusing which exampleVar is used here so you should use self
print(exampleVar)
print(self.exampleVar)
}
}
There's also this situation:
class example {
private var exampleVar = “this is the class scope variable”
func x() {
randomMethod { _ in
//This is not the class scope here, so we need to use self here.
//You will be flagged during build time of this if you don't use self.
print(self.exampleValue)
}
}
}
self is a property on the instance that refers to itself. It's used to access the class, structure and enumeration instance within methods.
When a method parameter has the same name as an instance property, you have to explicitly use self.myVariable = myVariable to make a distinction.
Notice that method parameters have a priority over instance properties.
struct Weather {
let windSpeed: Int
let chanceOfRain: Int
init(windSpeed: Int, chanceOfRain: Int) {
self.windSpeed = windSpeed
self.chanceOfRain = chanceOfRain
}
func isDayForWalk() -> Bool {
let comfortableWindSpeed = 5
let acceptableChanceOfRain = 30
return self.windSpeed <= comfortableWindSpeed
&& self.chanceOfRain <= acceptableChanceOfRain
}
}
// A nice day for a walk
let niceWeather = Weather(windSpeed: 4, chanceOfRain: 25)
print(niceWeather.isDayForWalk()) // => true
I have an elegant case for using self in Swift. I use it in blocks like this:
class MyBase {
private var baseValue: Int = 100
var block: ((Int)->())? = nil
func baseMethod(anotherValue: Int) {
guard let b = block else { return }
b(baseValue + anotherValue)
}
...
}
class MyClass {
init()
{
// Define base class block.
// This may hold self in block causing memory leaks
// if self is a strong reference
block = {
// indicate self is a weak reference
[weak self] (para) in
// guaranty self existence
guard let this = self else {return}
let value = this.value1 + para
// this call passes value to other obj's method
this.obj.method(value)
return
}
}
func callBaseBlock(otherValue: Int) {
baseMethod(otherValue)
}
private var value1: Int = 1 // ini value
private var obj: OtherClass // another class with method defined
...
...
}
This way, I guarantee that there will be no strong references to self in the block. The syntax is very clear. I use this way to prevent memory leaks.
I want to lazy/inline implement a protocol in Swift.
So in the point of the implementation I will have access to variables outside the protocol scope ,
Same as implementing a interface in Java without declaring a class:
class MyClass:UIView {
var someComponent:SomeInnerComponent = SomeInnerComponent();
var count:Int = 0;
var a = :SomeProtocol { //<----- IS THIS POSSIBLE, IF YES HOW ?
func a0() {MyClass.count--}
func a1() {MyClass.count++}
}
someComponenet.delegate = a;
}
protocol SomeProtocol {
func a0()
func a1()
}
editing----
thanks i look at this solution, and i didn't see how to access a variable of the parent class.
all the examples show an Anonymous class but no one of the examples is accessing the parent variables .
What you're looking for is an inner class (not necessarily an anonymous one), declared in a scope that lets it access the count variable of a MyClass instance, and that adopts a protocol defined at a different scope. Right now Swift has a few of those pieces, but it doesn't look like you can put them all together in any way that's as concise as what you might be looking for.
You might think about declaring an inner class:
class MyView: UIView {
let someComponent = SomeInnerComponent() // type SomeInnerComponent is inferred
var count = 0 // type Int is inferred
class Helper: SomeProtocol {
func a0() { count-- } // ERROR
// ...
}
init() {
someComponent.delegate = Helper()
}
}
But that won't work, because count is implicitly self.count, where self is a Helper instance, not the MyView instance that "owns" the Helper instance. And there isn't a way to reference that MyView instance (or its properties) from within a Helper's methods, because you could just as well construct a MyView.Helper() without having an existing MyView instance. Inner classes (or nested types in general) in Swift nest only in lexical scope, not in existential ownership. (Or to put it another way, since you referenced Java: all inner classes in Swift are like static inner classes in Java. There's no non-static inner class.) If that's a feature you'd like, though, it's probably worth telling Apple you want it.
You could also try declaring Helper inside MyView.init() -- in Swift you can nest type definitions anywhere, including inside functions or methods of other types. Defined there, it can refer to MyView's properties. However, now the type information for Helper is only visible inside of MyView.init(), so when you assign it to someComponent.delegate (whose type is just SomeProtocol), you can't make use of it... this crashes the compiler, even. (That's another bug to report, but it's hard to say whether the bug is really "compiler crashes on valid usage" or "code is bad, but compiler crashes instead of producing error".)
The closest solution I can come up with looks something like this:
class SomeInnerComponent {
var delegate: SomeProtocol?
}
protocol SomeProtocol {
func a0()
func a1()
}
class MyClass {
var someComponent = SomeInnerComponent()
var count = 0
struct Helper: SomeProtocol {
var dec: () -> ()
var inc: () -> ()
func a0() { dec() }
func a1() { inc() }
}
init() {
someComponent.delegate = Helper(
dec: { self.count -= 1 }, // see note below
inc: { self.count += 1 }
)
}
}
How it works:
Helper is an inner struct (could be a class, but a struct is simpler)
It implements the a0 and a1 methods, satisfying the requirements of SomeProtocol
The implementations of a0 and a1 call through to the closures dec and inc, which are stored properties (aka instance variables) of the Helper struct
You write (or otherwise specify) these closures when you construct a Helper instance (using the default member-wise initializer, Helper(dec: (Void -> Void), inc: (Void -> Void)))
Because you can write the closures when initializing a Helper, those closures can capture variables where you're calling the initializer, including the implicit self that refers to the MyClass instance creating the Helper.
You need both a0/a1 and dec/inc because you need closures (the latter), not methods, for capturing the enclosing state. And even though closures and funcs/methods are in many ways interchangeable, you can't create a method/func implementation by assigning a closure to a method/func name. (It'd be a different story if SomeProtocol required closure properties instead of methods, but I'm assuming SomeProtocol isn't something under your control.)
Anyway, this is kind of a lot of boilerplate and a layer of abstraction that you might not really need, so it's probably worth looking into other ways to architect your code.
Note: my example uses the closure { self.count -= 1 } where you might expect { self.count-- }. The latter doesn't work because that's an expression with a value, so Swift will interpret it as shorthand for the closure's return value. Then it'll complain that you assigned a () -> Int closure to a property that expects a () -> () (aka Void -> Void) closure. Using -= 1 instead works around this issue.
I would go for a different approach, I know this a pretty old topic but just in case someone else struggles with this issue:
class MyClass:UIView {
var someComponent:SomeInnerComponent = SomeInnerComponent();
var count:Int = 0;
init(){
// Assign the delegate or do it somewhere else to your preference:
someComponenet.delegate = ProtocolImplementation(myClass: self);
}
private class ProtocolImplementation: SomeProtocol {
let selfReference: MyClass
init(myClass: MyClass){
selfReference = myClass
}
public func a0(){
selfReference.count--
}
public func a1(){
selfReference.count++
}
}
}
protocol SomeProtocol {
func a0()
func a1()
}
By following this approach it's also possible to include the same protocol multiple times, lets say your Protocol supports a generic and you want to implement it twice. SomeProtocol< SomeObject > and SomeProtocol< OtherObject > could be both used this way if needed.
Kind regards