Swift Property - Getter Ivar

Swift property - getter ivar

Swift properties do not have the concept of separate, underlying storage like they do in Objective-C. Instead, you'll need to create a second (private) property and use that as the storage:

private var _document: UIDocument?
var document: UIDocument? {
    get {
        return _document
    }
    set {
        _document = newValue
        useDocument()
    }
}

If all you're trying to do is call useDocument() after the document property is set, you can omit the getter, setter, and private property and instead just use willSet or didSet.

Can stored property in Swift have getter and setter?

You have willSet and didSet.

That should be enough of an answer, but stackoverflow thinks it is too short :-)

Swift: Conditionally Set Private Ivar

Yes, it is possible with one nuance: swift lacks of implicit ivars in Objective-c sense. You have to do ivar on your own. And use === operator to check pointer equality.

import Foundation

class Setter: NSObject {

    private var __property: NSObject!

    var property: NSObject!{
        get {
            return self.__property
        }
        set {
            if newValue === self.__property { return }
            self.__property = newValue
        }
    }
}

Please check out this reference and this question for details regarding ivar concept in Swift.

ios interface iVar vs Property

The main difference is that a @property is visible to other objects, and can be accessed by these using an instance of your class.

You can use @synthesize in your implementation file to automate definition de getter setter functions in your implementation.

Updated (following @Graham Lee's suggestion)

According to the visibility specifier for your instance variable (@protected / @private / @public) , the ivar can be used in your implementation file, subclasses or other classes. The implicit value is @protected, so in your example it will be visible to your implementation file and subclasses.

@property hides _ivar when setter and getter are custom

The @property does not cause the ivar generation; rather, it's the implicit @synthesize. However, when you implement both the getter and setter, there is nothing to (implicitly) synthesize, so clang doesn't bother. If you add an explicit @synthesize statement, you'll get your ivar.

How would you effectively override a parent's computed iVar?

You override the var, just as given in the Swift interface:

override var frameOfPresentedViewInContainerView: CGRect {

Property getter as function

Starting with Swift 5.2, this is now possible, thanks to this Swift Evolution proposal.

Basically, key paths can now be used in places where functions are needed, like map/filter, etc.

For the example from the question, the usage would be along the lines of:

users.filter(\.isUnderaged)
users.map(\.firstName.count) // yes, chaining is also permitted

Must every ivar be a property?

It's not really necessary to declare properties for all ivars. A few points come to mind:

• If an ivar is only going to be assigned to once during the lifetime of the object, you don't really gain anything by declaring a property. Just retain/copy/assign during init and then release as necessary during dealloc.
• If an ivar is going to be changed frequently, declaring a property and always using the accessors will make it easier to avoid memory management errors.
• You can declare properties in a class extension in the .m file rather than the .h file if the properties and ivars are meant to be private.
• When targeting iOS 4.0+, you don't need to declare ivars at all in your header if you define a property and synthesize accessors.

So I generally use properties, but for things like a NSMutableArray that an object allocates during init and uses to hold a bunch of whatevers, I'll use a plain old ivar since I'll never be reassigning the ivar.

Property syntax, Am I accessing the ivar directly or going through the getter/setter?

• name = @"Geoff"; is setting the ivar directly.
• [ name release ]; is accessing the ivar directly.

If you don't see self. and you aren't calling a method to get or set the variable, then you are accessing the ivar.

For more details, see The Objective-C Programming Language.

iOS automatic @synthesize without creating an ivar

In my working with this, I've noticed the following behavior.

1. If you have a readwrite property, don't have a @synthesize, have a getter and don't have a setter, then it will generate the iVar.
2. If you have a readwrite property, don't have a @synthesize, don't have a getter, and have a setter, then it will generate the iVar.
3. If you have a readwrite property, don't have a @synthesize and have both a getter and a setter, then it will not generate the iVar.
4. If you have a readonly property, don't have a @synthesize and don't have a getter, then it will generate the iVar.
5. If you have a readonly property, don't have a @synthesize and have a getter, then it will not generate the iVar.

From this, I think the general rule is that if you don't have a @synthesize, and have all the methods needed to fully implement the property, then it's assumed to be dynamic and doesn't generate the iVar.

At any rate, if you want to ensure that an iVar is not generated then declare it as @dynamic.

---

Clarification on @dynamic

From Declared Properties in The Objective-C Programming Language:

You use the @dynamic keyword to tell the compiler that you will fulfill the API contract implied by a property either by providing method implementations directly or at runtime using other mechanisms such as dynamic loading of code or dynamic method resolution.

To me this reads like it OK to mark a property as @dynamic even when you are directly implementing the getter and setter.

---

Related Topics