I have a class that conforms to my own protocol that has optional methods. The reference to that class's object is also an optional. In other words, the object may be present and it may have implemented the method in question. But how do I call it?
I have code like this:
if let theDelegate = delegate {
if let result = theDelegate.delegateMethod() {
}
}
but Xcode complains that the "value of optional type '(()->())?' not unwrapped". it wants me to change the second half of line 2 in the example to "theDelegate.delegateMethod!()", but force unwrapping defeats the purpose of what I am trying to do. How am I supposed to call this method? Note that my method has no parameters or return values.
According to the documentation, optional methods should be called like this:
if let theDelegate = delegate {
if let result = theDelegate.delegateMethod?() {
}else {
// delegateMethod not implemented
}
}
Optional property requirements, and optional method requirements that return a value, will always return an optional value of the appropriate type when they are accessed or called, to reflect the fact that the optional requirement may not have been implemented.
Related
Basically, I have a class called UserData and multiple initializers for it. In particular, I have a copy initializer which looks like:
init (_ origin: UserData){
// copy over everything
}
And another initializer which is used when I need to read the data from a file:
convenience init (Read _: Bool) {
// read stuff and call another initializer
}
Then I always got a compiler error saying cannot convert Bool to UserData whenever I tried to do var something = UserData(true).
I tried adding label, but compiler said extroneous label since there is only one parameter. I could make a workaround by adding another random parameter to the second initializer. But why is the compiler always trying to interpret the call to something does not match the type while there is another that matches the type?
Swift has no problem distinguishing two initializers with one parameter. The error is because of how the second one is defined. It should be:
convenience init (_ read: Bool) {
// read stuff and call another initializer
}
I have swift class with various properties, some of which have optional types.
class UserObject: PFUser{
//optional property
var optionalPhotoURL:String? {
get {
if let optionalPhotoURL:String = objectForKey("optionalPhotoURL"){
return optionalPhotoURL
}
//not needed but just for emphasis
return nil
}
//I am unable to set UserObject.optionalPhotoURL = nil with this setters
set {
if let newPhotoURL:String = newValue! {
setObject(newPhotoURL, forKey: "optionalPhotoURL")
}else{
self.optionalPhotoURL = nil
}
}
}
}
I am unable to set optionalPhotoURL as nil, if it already had a previous value assigned to it.
I guess my question is, how do i "unset" an optional property with custom setter?
Update
These setters all crash
set {
if let newPhotoURL:String = newValue {
setObject(newPhotoURL, forKey: "optionalPhotoURL")
}else{
self.optionalPhotoURL = nil
}
}
and this
set {
if (newValue != nil) {
setObject(newValue!, forKey: "optionalPhotoURL")
}else{
self.optionalPhotoURL = nil
}
}
What you have here is a computed property.
Swift properties can either be computed or stored. We can observe value changes in our stored properties by using didSet and willSet but here we still have a stored property.
In your case, since you have overridden set and get*, you don't have a stored property, you have a computed property. If you want a computed property to have a backing storage, you must create that independently.
So you may want something like this:
class FooClass {
private var storageProperty: String?
var accessProperty: String? {
get {
return self.storageProperty
}
set {
self.storageProperty = newValue
// or whatever logic you may like here
}
}
}
*: You can't override set without also overriding get. You can however override get without overriding set--this makes a readonly computed value.
Moreover, it's important that we implement our storage properties in this way over relying on key-value coding.
For starters, setObject(forKey:) approach doesn't even work on pure Swift types. This will only work on objects which inherit from Objective-C types. It's an inherited method from NSObject's compliance to NSKeyValueCoding protocol. Why the base object of Objective-C conforms to so many protocols is beyond me... but it does and there's nothing we can do about it.
If we have a code base in which some of our objects are inheriting from Objective-C objects (which basically any project will have, UIViewController, etc), and some of our objects are pure Swift objects (which you will tend to have when you're creating your own Swift classes from scratch), then our Swift objects will not be able to implement this same pattern. If we have some objects of both types, we'll either have to implement the pattern I show above for all of them (and then we have consistency) or we'll have to implement one pattern for some types and another for other types (Swift structs would definitely have to implement the above pattern, you can't just make them inherit from NSObject) (and then we have inconsistency, which we don't like).
But what's far worse about setObject(forKey:) is that the first argument of this method always will be of type AnyObject. There is no type safety to the method at all. Where things are stored via setObject(forKey:) is based purely on the key which we use. When we use setObject(forKey:), we take a pile of type-safety advantages that Swift gives us and we throw them out the window. If we don't care to leverage the advantages Swift gives us over Objective-C, why are we writing it in Swift at all?
We can't even make the stored property private when we use setObject(forKey:). Anyone who knows the key can call setObject(forKey:) and set that object to whatever they want. And that includes objects which are not strings. All we have to do to introduce a crash to this codebase is write a class extension or subclass which has a key collision on a different type other than what you've used (so maybe an NSData value for the same key). And even if it doesn't happen to be a different type, simply duplicating the same key for multiple properties is going to introduce bugs... and bugs that are hard to debug.
Never set a value of a computed property in its set scope by calling itself !
This causes an infinite loop and the app will crash.
I don't know which API setObject:forKey belongs to, but in the case of nil you are supposed to remove the object
set {
if let newPhotoURL = newValue {
setObject(newPhotoURL, forKey: "optionalPhotoURL")
} else {
removeObjectForKey("optionalPhotoURL")
}
}
Your property optionalPhotoURL is a computed property, it does not store any values:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Properties.html
You might want to create an additional property which actually stores the value. However, why do you want to set it to nil, since you are not deleting they object in case of nil.
As per Apple docs, optional chaining is the following:
You specify optional chaining by placing a question mark (?) after the optional value on which you wish to call a property, method or subscript if the optional is non-nil. ... optional chaining fails gracefully when the optional is nil ...
My interpretation of this is that a construction as the following is optional chaining:
someMasterObject.possiblyNilHandler?.handleTheSituation()
...and that the above line would call the handleTheSituation method if the handler is not nil, and fails gracefully (line skipped) if the handler is nil.
However almost all examples I see of optional chaining use the "if let" construction, as per:
if let handler = someMasterObject.possiblyNilHandler{
handler.handleTheSituation()
}
In fact, the documentation and examples I have found on the net make such heavy use of the "if let" construction in relation to optional chaining that it seems as if that IS optional chaining.
Am I correct, however, in assuming that my first example is a supported use of optional chaining and that the if let construction is another construction using (or being intimately tied to) optional chaining?
Optional chaining is useful in more cases than just optional binding (if let):
person?.name = "Fred" // assign "Fred" to name property if person is not nil
person?.congratulate() // call congratulate method if person is not nil
let name = person?.name ?? "none" // nil coalescing operator
let age = dict?["age"] ?? 0 // subscripting an optional variable
if var name = person?.name { // optional binding using var instead of let
The conclusion is correct - let is an independent, but useful, construct. In context it introduces a binding only within the if-body and executes the if-body only if the bound value is not-nil. (Technically it unwraps an optional binding.)
let does not affect how the expression on the right (with or without chaining) is handled. For instance, if someMasterObject were optional/nil it would fail and not "chain" - even with let.
When one or the other (or both) is more "correct" depends on the situation: eg. what is being chained and what the corrective action should be.
For instance, if someMasterObject could be nil, we might have the following which uses both chaining and let. Also note how the return value matters and is not simply discarded or "nil on failure":
if let handler = someMasterObject?.possiblyNilHandler{
return handler.handleTheSituation()
} else {
return FAILED_TO_CALL
}
Then compare it with a non-equivalent chained form, which would only return nil in the failed-to-call case, but nil might be a valid return value from handleTheSituation!
return someMasterObject?.possiblyNilHandler?.handleTheSituation()
On the other hand, do consider that there is always direct translation of chaining to nested if-let statements:
result_of_expression = someMasterObject?.possiblyNilHandle?.handleTheSituation()
if let master = someMasterObject {
if let handler = master.possiblyNilHandler {
result_of_expression = handler.handleTheSituation()
} else {
result_of_expression = nil
}
} else {
result_of_expression = nil
}
Calling methods through optional chaining is perfectly alright - you do not need an if around it. If the optional value happens to be nil at the time of the call, your code would not throw an exception. However, you wouldn't be able to find out whether the method has run or not.
However, typically you want to place an if around the optional chaining method call to detect if the method has been called or not:
func printNumberOfRooms() {
println("The number of rooms is \(numberOfRooms)")
}
if john.residence?.printNumberOfRooms() != nil {
println("It was possible to print the number of rooms.")
} else {
println("It was not possible to print the number of rooms.")
}
Link to the book chapter.
Note that the nil check works even though the function in the example has no return value. Since it is called on an optional value using optional chaining, the type is Void?, not Void, which makes the comparison possible.
Is it correct that properties for an optional element cannot be modified with Optional chaining?
class Something {
var mark:Person?
func changeAge{
mark = Person()
mark?.age = 40 <--- IT DOESN'T WORK.
mark?.sayHello() <----- IT WORKS
}
}
Trying to perform a change on the age property I get this error: Cannot assign to the result of this expression but I can call the method sayHello. Since the two elements booth appertain to an instance of Person I can't understand why I can't access its properties but I'm allowed to access methods.
Edit: I know that I could use forced unwrap or optional binding... I'm just asking why I can't access properties that way but I can access methods.
Well, you can't access the method if it is nil - it's only called if mark? isn't nil. Assigning to the property is meaningless if mark? is nil, and if it isn't (and you're sure it isn't), you can assign to mark!. If you are unsure about whether it is nil, use:
if let m = mark {
m.age = 40
}
Currently, I am seeing something strange behavior.
class DataManager1
{
let THE_ID = "SOME_ID_STRING"
let _con1 = CKContainer(identifier: THE_ID) // error
// error: 'DataManager1.Type' does not have a member named 'THE_ID'
}
class DataManager2
{
let THE_ID = "SOME_ID_STRING"
let _con1:CKContainer?
init()
{
_con1 = CKContainer(identifier: THE_ID) // no error.
}
}
In C++ we have a defined initialization order between instance member variables. I expected something similar, but actually I couldn't find a mention for that form the manual.
Does Swift has a defined initialization order of properties? If it does, what is the rule, and where can I find the rule?
This is due to the fact that you're using a Closure (a Function is just a special case of Closure that is unnamed) to initialize the _con1 property with a default value.
From the Apple provided iBook:
If you use a closure to initialize a property, remember that the rest
of the instance has not yet been initialized at the point that the
closure is executed. This means that you cannot access any other
property values from within your closure, even if those properties
have default values. You also cannot use the implicit self property,
or call any of the instance’s methods.
Even though the note above refers specifically to closures, it seems that trying to set the default value for a property to be that of another property directly also does not work.