What is the best way to declare a list of scalar values ​​in Swift

I was wondering: what is the best way to declare an unordered list of scalar values ​​in Swift, which are fully supported by the character and need to be checked by the compiler?

Let's say I want to declare a list of LetterSpacing values ​​that I want to get and use in my code through their characters.

I understand that I have to declare a fast enum as follows:

 enum LetterSpacing: Double { case Short = 1.0 case Medium = 2.0 case Large = 3.0 } 

This works great and gets compiler checks, but the annoying part is that I need LetterSpacing.XXX.rawValue to access the base value every time. .rawValue prevents me from pointing this out a bit everywhere.

I suppose this would not make sense or it would be inappropriate to declare a struct with three static let Short = 1.0 , etc.

So how would you handle such cases? Can I add some protocol / extension magic attributes to existing types to be able to enumerate Short as an eigenvalue? (i.e. let size = LetterSpacing.Short will be of type Double and set to 1.0 )

+6
source share
2 answers

enum will be preferable for several reasons.


First, enum actually ends up with less memory. This is because Swift optimizes enum values ​​by one byte (regardless of the original value), and we only get the full value when we call rawValue by enum value. Paste the following code on the playground to see:

 struct LetterSpacingS { static let Short: Double = 1.0 } enum LetterSpacingE: Double { case Short = 1.0 } sizeofValue(LetterSpacingS.Short) sizeofValue(LetterSpacingE.Short) 

double is 8 bytes, and enum is only 1.


Secondly, the importance of the first point extends beyond the entire memory. It can also be applied to the effectiveness of our program. If we want to compare two values ​​from our structure, we compare 8 bytes. If we want to compare our two enum values, we only compare one byte. In this particular case, we have the 1 / 8th number of bytes. And it's just double. Note that Swift strings can also have strings as substitution types. Comparing two strings can be extremely expensive, but just comparing one byte, they are hidden in enum .


Third, using an enumeration, we do not compare floating point numbers that you really do not want to do, generally speaking.


Fourth, using an enumeration gives us some type safety that we cannot get with a constant structure. The entire structure of constants allows you to define several predefined constants to use.

 struct LetterSpacingS { static let Short = 1.0 static let Medium = 2.0 static let Long = 3.0 } 

But now, what does a method look like that expects one of these values?

 func setLetterSpacing(spacing: Double) { // do stuff } 

And now, what happens when Joe-Coder comes in and does:

 foo.setLetterSpacing(-27.861) 

Nothing stops him. Requires double, any double. It may not be so often, but if it is in the library that you distribute, you leave yourself open to questions and comments, for example: "When I pass the value 5.0, it does not look like that at all!"

But compare this with enum .

 func setLetterSpacing(spacing: LetterSpacing) { // do stuff } 

And now we get only three predefined options for what needs to be passed into this argument.

And outside of your internal use for values ​​stored in enum , you will have to use rawValue too much.


The fifth reason is not a serious reason to use an enumeration over a structure, but basically just to eliminate one of the reasons suggested for using a structure over an enumeration. Swift enumerations can be nested in other types, and other types can be nested in Swift lists. You do not need to use struct for nested types.

+6
source

I do not understand why creating a Struct with three static constants would be inappropriate. I see a lot of Swift code (also from Apple) that does this.

Structures allow you to create beautiful hierarchies:

 struct Style { struct Colors { static let backgroundColor = UIColor.blackColor() ... } struct LetterSpacing { static let Short = 1.0 } ... } 
+2
source

Source: https://habr.com/ru/post/989807/


All Articles