This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
dynamic properties in objective c
How can I add properties to an object at runtime?
Is there a way to actually create properties in runtime dynamically in iOS?
I am experimenting something here, and just wanted to see if it be possible?
Thanks.
Properties are mapped to methods so you can add properties dynamically the same way you add methods dynamically using -[NSObject forwardInvocation:] and -[NSObject methodSignatureForSelector:] though you will have to use method syntax to call these methods and it can get complicated if you want to use primitive type properties.
you can generate types dynamically using ivars and methods, but there is not a means to get all the functionality of a declared property via one or two runtime calls.
a handful of functions should be all that is needed to accomplish the common routines, but a complete implementation would require some work and some syntactical noise.
Related
Headline: description called by super.init()
This is a new take on an old question. As a primarily Swift programmer I tend to not use NSObject for class definitions because of the residual side effects of Objective-C. Like if I have a read-only property called length and I then want to create a setter function called setLength, I get warnings about it conflicting with a similar definition from Objective-C. I just discovered the set(var){} setter. If I subclass a Cacoa class like UIDocument, etc. that inherit from NSObject, I have to live with these side effects.
I have a class that uses two other classes in the property definitions, none of them NSObjects. This class has a description computed variable that uses the description computed variables for the other two classes in its composition. All three classes need to conform to the CustomStringConvertable protocol. Ok, everything is good.
At some point this class got upgraded to being a UIDocument and the CustomStringConvertable became redundant and was removed. Everything still works.
Here is what I found out today. I wanted to break at a point in the program where it was printing one of the two properties and as a convenience I set the break point in the description variable for that class, thinking that it should only be called at the point I am interested in, where it is printed out. What I discovered is that the description variable gets called during all the super.init() of the UIDocument sub-class! And there were a few of them. I think composing strings as being relatively expensive but didn't care because they were only used in debug, but with them being called and who knows how they are used in super.init(), I need to change this.
I checked another UIDocument class in the same program that has 200 files associated with it and it is also calling description in super.init().
Does anyone have any input on the Best Practices for using description vs debugDescription?
I'm going to answer my own question as a matter of documentation.
I switched the UIDocuments subclasses to define and use debugDescription. I am debugging some code that loads all the files and does some manipulation and I was able to reduce the load time from 9.8 seconds to 6.8 seconds.
I also went through all the places where the Swift 3 conversion added String(describing:) to the program and found I could change a lot of them to using debugDescription and eliminate the String(describing:) wrapper.
I think the best practice is to only define and use debugDescription and for my non-NSObjects change conformance from CustomStringConvertable to CustomDebugStringConvertable.
This question already has answers here:
Why convenience keyword is even needed in Swift?
(6 answers)
Closed 5 years ago.
The convenience keyword in swift completely confused me. It doesn't seem useful at all. Calling other initializer (or say constructor) in same or super class is a very common feature in object oriented languages, like Java, C# and etc. If any member is not initialized, the compiler gives a warning. It seems the only thing it does is to restrict the call to other initializer to same class, which makes it seems even more useless. So, why bother having this keyword at all?
I saw some other threads online discussing about this but none of them is really convincing.
Does anyone know the real purpose of this keyword?
From The Swift Programming Language:
You do not have to provide convenience initializers if your class does not require them. Create convenience initializers whenever a shortcut to a common initialization pattern will save time or make initialization of the class clearer in intent.
So, basically, they are for convenience.
This question already has answers here:
Difference between static function and singleton class in swift [closed]
(3 answers)
Closed 6 years ago.
I have made a class that will contain all the utility methods. So, instead of making it as a singleton, I have marked the methods as static and accessing those methods by the ClassName.methodName without the need for instantiation.
Is this approach OK?
Just consider that a singleton is used in order to ensure that only one instance exists for a given class, and that there’s a global access point to that instance.
I believe that having all utility functions marked as static within a class is a good approach since, as you have stated, you will need to use ClassName.methodName in order to use them.
In addition, based on what you want to achieve and the information provided by this link, I would reassert that having a class with static methods is the best alternative.
I've been trying to find the best way to implement a stored property in an extension, and came across this question: Swift extension stored properties alternative. However, I have not found a reason why in the discussion or anywhere else. Is there a reason why stored properties are not allowed in Swift? And if so, what is the reason?
Extensions are for extending the functionality of an existing class without changing the memory structure. It's more or less syntactic sugar. Imagine you could add stored properties and methods, what would it be? Nothing else but inheritance. So if you like to add new properties and methods just inherit from the class.
In Objective-C, all objects can be treated as type id, and nearly all objects inherit from NSObject. (Blocks don't, but that's about the only exception.)
Thus it's possible to create an Objective-C category that extends ALL Objective-C objects. (ignoring blocks)
In Objective-C, I created an extension to NSObject that uses associated objects to optionally attach a dictionary to any NSObject. That enabled me to implement methods setAssocValue:forKey: and assocValueForKey: that makes it possible to attach a key/value pair to any NSObject. This is useful in lots of circumstances.
It makes it possible to add stored properties to a category, just for example. You just write a getter/setter that uses the associated value methods to attach a stored object, and away you go.
It also makes it possible to attach values to existing system objects at runtime. You can hang data or blocks of code on buttons, or do whatever you need to do.
I'd like to do the same thing in Swift.
However, Swift does not have a common base class for all objects like Objective-C does. AnyObject and Any are protcols.
Thus,
extension AnyObject
Won't compile.
I'm at a loss as to where to "attach" my setAssocValue:forKey: and assocValueForKey: methods in Swift.
I could create a base class for my extension, but that defeats the point of using an extension. I could make my base object an Objective-C NSObject, but that means all my objects have to be NSObjects, and Swift objects are not NSObjects by default.
(BTW, this question applies to both the Mac OS and iOS platforms)
No. You've pretty much answered your own question--Swift objects don't have a base class, and the only real way to get around it is to inherit from NSObject.