|
I was playing around with the
What is the purpose of it here? How is this useful and why is this valid code that runs? It doesn't seem that useful. Obviously, it's useful for the following reasons:
Is there any other place I can use the |
|
Always check the Language Guide. From the section on Overriding Properties:
And from the section on Preventing Overrides:
|
|
I took a look at some of that documentation a bit closer and did some additional research. I've determined that there's really only two scenarios where you would want to use the
The same as I had in the first post. When considering stored properties, Swift does not allow you to override them as there is no behavior to override. Thus, it doesn't seem to make much sense to use the If it doesn't make sense to override a stored property, then what's the point of being able to still add the keyword in front of a stored property? I'm still at the conclusion that using The documentation refers to properties in the context of them actually having behavior to override. If they're stored properties then there's nothing to override... so there's no point in the keyword. The more and more I play with Update: Perhaps this is the reason why? You could do something like this:
I have a stored property in the Engineer class, which will then be overridden to have a didSet property observer added on to it. That could possibly yield the need for a |
|
You can override a stored property with a computed property. (Obviously in this particular example you can't, because you've declared
But if you declare |
|
Thanks. Just to clarify, I was talking about how you can't override stored properties with other stored properties. I can see how what I stated earlier could be a bit confusing:
What I meant by that was something like this:
There is no new behavior being added to hoursWorked, which produces an error. I guess it's not that there isn't any behavior to override, it's that stored properties and the way they are designed do not enable any new behavior to be implemented, without becoming computed properties or adding on property observers. Property observers cannot be thought of as true "behavior" because they are limited to what happens only when you write and there are missing capabilities there (like when you read). Thus, stored properties can't really "override" anything as they can't offer any behavior to add on their own. At least that could be a possible theory. As you'll see later on, it seems debatable. It's probably easy to mix up overriding with changing behavior compared to changing values of properties, like in this example. While I was looking through this a bit more, I started to think of a few more things that I would like to clarify:
When looking over all of this, it really seems like I just left out a small detail in my very first post. I originally said there are two scenarios where
I think this entire misconception can be fixed with a simple change to my original statement: The
Therefore, there is an actual purpose for using I forgot about that second detail, and I think knowing that small thing answers my question. Please let me know what you think of this conclusion! :) While on this subject, it could be helpful to map out what can and cannot override what. I am certain this is correct (and tested code to check): Computed Properties:
Stored Properties:
Property Observers:
The use of Sorry! This post is a bit long, but I also just view of these forums as my own notes as well! :) |
SAVE 50% All our books and bundles are half price for Black Friday, so you can take your Swift knowledge further without spending big! Get the Swift Power Pack to build your iOS career faster, get the Swift Platform Pack to builds apps for macOS, watchOS, and beyond, or get the Swift Plus Pack to learn advanced design patterns, testing skills, and more.
This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.