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.
Related
This question already has an answer here:
Extension may not contain stored property but why is static allowed
(1 answer)
Closed 5 years ago.
Quoting the Swift Programming Language Guide :
Extensions can add new computed properties, but they cannot add stored properties, or add property observers to existing properties.
Why is that ? What's the technical or logical reason behind this ?
In simple words
Because properties need storage, adding properties would change the memory structure of the class
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:
What is the rationale behind having companion objects in Scala?
(7 answers)
Closed 7 years ago.
As we know we don't have static methods in scala. If we have to achieve that taste we declare that class as object. But the problem is that when we declare class as object then all methods present in that object becomes static. And in class all methods all non-static. What I want is that to have static as well as non static methods in the same class, Is it possible? Definitely it would be possible but how??????
To do what you are trying do in Scala you create an object and a class of same name. Put static in object and instance members in Class version of it. This object is called a companion object.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I was wondering why you cant use the static keyword in a class.
I know that you can use it in a struct but not in a class
Does anyone know why they choose for this?
And if so are there any advantages for letting static away?
It is a terminological bêtise. What Apple did was decide that you use static in an enum or struct and class in a class. In my view this was a very foolish decision, as they are exactly parallel to one another. Many people have posted on the dev forums suggesting that they just call them all static.
The outcome is a candidate for Occam's Razor: two phrases, e.g. static property and class property, or static method and class method, that mean exactly the same thing. And then they try to cover their tracks in the documentation by adding a third term as an umbrella, "type property" (meaning a static-or-class property) or "type method" (meaning a static-or-class method), which just makes the situation even worse.
The badness of the situation is also revealed by what you have to do in protocols: you declare a class property in a protocol and then if a struct adopts it, it calls that a static property. Same thing with a class method in a protocol; an adopting struct must call that a static method. You'd think that this alone would have told them they'd done a bad thing.
Edit: The more I think about it, the more I like the proposal put forth by newacct in a comment below. If Apple had simply used the umbrella keyword type here as part of the language, the whole problem would have been solved. We could have declarations type var, type let, type func, and this would work equally in enums, structs, classes, and protocols across the board.
From the Swift Language Guide on Methods, Apple has chosen to differentiate the syntax used, based upon the fundamental Type that you're building.
Classes declare "Type Methods" with the keyword Class. Example:
class MyClass {
class func myFunc(){ ... }
}
Structs declare "Type Methods" with the keyword Static. Example:
struct MyStruct {
static func myFunc(){ ... }
}
In both cases, crating a Type Method allows you to invoke the method without first creating an instance of the class or struct.
Whereas a non class/static function would require something like
let instance = MyClass()
instance.myFunc()
... declaring the variable as a Type Method allows something like
MyClass.myFunc()
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.