Experience of developing an application on Swift, observations and conclusions
This article came out of the programmer’s report after the “experience” of developing a small application in the new Swift language.
Dima has been programming for almost two years and studies languages independently. Documentation, someone else's code. He does not claim to be a professional, but his experience may be useful to many who are thinking of starting to code in Swift. Experiments, observations and conclusions. We invite to the discussion! Further, the text of the author.
')
When I started writing for iOS (and it was not so long ago), Objective-C confused me a lot. Not that it was difficult to understand, just the syntax looked very unusual. Over time, I got used, of course, but when I found out about the appearance of Swift, at the first opportunity, a new project began to write on it.
In addition, there are moments about which you can burn yourself. I wanted to speculate about all this. I tried to describe and summarize the controversial points that I noticed in the process.
By the end of development and by the end of writing this article, I updated Xcode, and with it Swift to version 1.2. It turned out that some of the problems I mentioned have lost their relevance. Nevertheless, I left them in the text, because they illustrate the conclusions that are not lost relevance.
The first significant weakness is compatibility with pure C. As we all know, Swift is fully compatible with ObjC. ObjC is fully compatible with C. Is Swift compatible with C? Also yes. The creators of the swift made special bridges not only to ObjC, but also to C. And here is the documentation section on how to interact with the C API. The problem I had when I tried to use the Core Foundation (which is just the C-asy API). CFNotificationCenterAddObserver accepts a pointer to a C function as a parameter (there are probably other useful functions from this library with this one). In Swift, you can create a pointer to the C function (provided by the CFunctionPointer), but you can't write it in the swift file itself, the syntax is different! That is, for ObjC, compatibility with C is that you can simply start writing in C, respectively, and use C code from other places (libraries), and Swift can only use libraries or third-party C, or objc files. A bit different compatibility. It would seem a trifle, but here's a specific situation for you: if you write only on Swift, you cannot use Darwin notifications.
Let's move on to more general things. Speaking of Swift "fully compatible" [c ObjC], it should be kept in mind that all things from ObjC are accessible in Swift not directly, but through bridges. The simplest examples are: NSArray -> [AnyObject], NSDictionary -> [NSObject: AnyObject], and the Swift strings (String) seem to have functions from NSString, but again, not all (for example, length) are a bunch of global functions starting with objc_. And in most cases when transferring something from ObjC to Swift, we see AnyObject. I know the reasons, but now it’s not about them, but about the consequences. Of course, AnyObject is needed, as an opportunity, situations are different. But its use contradicts the ideology of the language a bit, because Swift is characterized by strong typing (which should increase the reliability of the code). And when using any frameworks from Apple, we see AnyObject everywhere in the functions, because they are all on ObjC. As a result, we must match the result of every second function from the standard library to the required type. And God forbid you do not guess or confuse what should be the type! [I know that you can do a check with is, but suddenly all the brevity and simplicity of the code disappears somewhere].
So, we are given a new, more reliable language, due to the fact that we are obliged to indicate the type of variables. But the functions of standard libraries often return non-typed objects. Of course, the condition of "full compatibility" is not violated, but at this moment I have a little jarring.
A similar situation, albeit in a lighter form, with optional variables. Optional variables may well be called language tools, but if you write in the style that Swift assumes, then you have to use them very infrequently. The functions of the NS classes return optional one. And it also makes change the programming style for the sake of compatibility.
[ deprecated in 1.2 ]
Let's go back to the details. There are things in the Foundation, which are still completely unavailable in Swift. For example, the NSDecimal class. Although the documentation had a description on the swift, it was impossible to use it. Thus, if in the ObjC function there was NSDecimal as an input or output parameter, you simply did not see it in the swift. And if they wrote, it was not compiled because of an error. However, if you believe Google, except for users of the Core Plot library (because of which I also encountered this problem), this class was not really needed by anyone. True, in 1.2 it can now be used. But this is something that only I encountered. And for sure, even in the comments there are other examples of inaccessible classes.
See for yourself, but I, considering all the above, when assessing the compatibility of Swift and ObjC, would rather use the words “almost complete”.
I don't really like Objective-C. And I almost love Swift. According to the main page of Apple's Swift , this language is both innovative and modern. I will not argue with that, but according to my feelings, he has not yet grown to the point where they can be used painlessly. Some shortcomings are evident almost immediately when they get acquainted with the language, but some are not quite obvious. I will simply list everything that is in the way now, but I hope it will be corrected in the future.
[ deprecated in 1.2 ]
The first is the difficulty in debugging. While dictionaries and arrays in ObjC we could open and view directly in the debugger panel, standard swift classes cannot be opened and viewed. Debagger only shows their type. As I said, this concerns the standard classes, if you use NSDictionary or NSArray, they are expanded as before (it’s understandable, the Foundation is on ObjC). Alternatively, you can use NSLog, but this is obviously less convenient.
Similar to the previous situation with optional variables. Whatever the type, in the debugger you will see only nil this variable or some, and you will not achieve anything from it anymore.
Fixed in 1.2. And some, and classes swift now you can watch.
I don’t know what to call this situation, but the following happens: while analyzing the swift code in Xcode, something breaks, it gives an error about it and the whole syntax highlighting disappears. Then this is something, apparently, is restarted, the backlight appears again, and even autocomplete works again. But here these faults occur at the moment when the code is not compiled (for example, the bracket is open, etc.), and sometimes when I have not yet given the name of a variable or function. Although Xcode does not crash, and that is good, but nevertheless, all this does not look very elaborated.
String - standard swift language class. It has an automatic bridge to NSString. However, the length function does not have. I know that there is a reason for this, but the fact remains: such a simple function like the length of a string is made more difficult in Swift.
Very special case. objc_setAssociatedObject takes as its last parameter a type parameter - typealias objc_AssociationPolicy = UInt. Next to the type, variables are defined that define this policy OBJC_ASSOCIATION_ASSIGNb, OBJC_ASSOCIATION_RETAINb, OBJC_ASSOCIATION_COPY, etc., and they are of type Int. Why? Why should I explicitly lead and write 2 times longer: write objc_AssociationPolicy (OBJC_ASSOCIATION_COPY)? I hope someone will explain (comments ?!)
Swift is a new language, even from the moment of the announcement, even a year has not passed. It is actively developing, which is good news, and it is changing, which makes you think a bit. And sometimes, changes can significantly change the programming style, for example, before the constants had to be assigned immediately upon declaration, and from version 1.2 - after. Others are just a syntax change (countElements -> count). Literally at the time of writing this text I updated Xcode (remember, version 6.3 was released on 04/04/15 and contains a new version of swift 1.2), and now the project is not compiled. Almost everything as asks to be replaced with as!, Well, it is clear from the description of changes to the new version. But the unobvious change: NSDictionary is now for some reason not automatically converted into [NSObject: AnyObject], like NSString in String, and NSSet -> Set, and NSArray -> [AnyObject] is also no longer, well, you understand how works. And before that. And now - no. There are certainly good reasons for this, but I'm not talking about them now. Reverse assignment, by the way, still works without an explicit cast.
Xcode has a function for migrating to the latest version of SWIFT. In my experience update, alas, does not work as it should. All inconsistencies of the new version were removed only after the third carrying out of this operation (previous times also worked, but not all were removed), but as a result, the code did not become compiled. In one place, the utf16Count function remained uncorrected, although before the first conversion, Xcode offered an autochange, which now had to be replaced manually. That is, I had to do the conversion 3 times, because each time he did only part of the replacements, and then also edit the code in one place manually. I'm afraid to imagine the inconvenience experienced in large projects. Fearing a similar situation, I didn’t want to update Xcode before the project was completed, although the update was already officially released. Here is an indicative situation with updates.
And I’ll also briefly mention the undocumented global functions, which, in my opinion, are also a sign of the youth of the language: countElements, dropFirst, dropLast, first, last, prefix, suffix, reverse. So take a playground and try.
Debag already finalized, NSDecimal appeared. This is from the corrected deficiencies, in the list of changes 1.2 there are, of course, other improvements. It is seen that the work on the language continues to be actively. And I have no doubt that over time, and other shortcomings correct, and add chips. But there is a "but." Foundation no one will rewrite: ObjC is not going anywhere. In the meantime, all the core libraries are written in ObjC, Swift cannot be written in the style for which it was designed, since you will always need to interact with ObjC. Well, I hope to someday see a new framework designed specifically for SWIFT. It sounds fantastic, but if Apple plans to complete the transition to Swift, then I guess it will happen sooner or later. After all, there is the Core Foundation, and there is the Foundation.
I invite to discussion.
Dima has been programming for almost two years and studies languages independently. Documentation, someone else's code. He does not claim to be a professional, but his experience may be useful to many who are thinking of starting to code in Swift. Experiments, observations and conclusions. We invite to the discussion! Further, the text of the author.
')
Introduction
When I started writing for iOS (and it was not so long ago), Objective-C confused me a lot. Not that it was difficult to understand, just the syntax looked very unusual. Over time, I got used, of course, but when I found out about the appearance of Swift, at the first opportunity, a new project began to write on it.
In addition, there are moments about which you can burn yourself. I wanted to speculate about all this. I tried to describe and summarize the controversial points that I noticed in the process.
By the end of development and by the end of writing this article, I updated Xcode, and with it Swift to version 1.2. It turned out that some of the problems I mentioned have lost their relevance. Nevertheless, I left them in the text, because they illustrate the conclusions that are not lost relevance.
About compatibility
The first significant weakness is compatibility with pure C. As we all know, Swift is fully compatible with ObjC. ObjC is fully compatible with C. Is Swift compatible with C? Also yes. The creators of the swift made special bridges not only to ObjC, but also to C. And here is the documentation section on how to interact with the C API. The problem I had when I tried to use the Core Foundation (which is just the C-asy API). CFNotificationCenterAddObserver accepts a pointer to a C function as a parameter (there are probably other useful functions from this library with this one). In Swift, you can create a pointer to the C function (provided by the CFunctionPointer), but you can't write it in the swift file itself, the syntax is different! That is, for ObjC, compatibility with C is that you can simply start writing in C, respectively, and use C code from other places (libraries), and Swift can only use libraries or third-party C, or objc files. A bit different compatibility. It would seem a trifle, but here's a specific situation for you: if you write only on Swift, you cannot use Darwin notifications.
Solution from the Internet
The pointer to the C function in the swift is the CFunctionPointer. Theoretically, it can be created from a pointer to a swift function, however, I don’t understand how it all works. Description from the Internet, how to create a pointer to the C-function in the swift, looks like this:
In the C, it will have a CFunctionPointer <() -> Int32> type. To create CFunctionPointer, COpaquePointer is needed, eg:
let pointer = UnsafeMutablePointer <() -> Int32> .alloc (1)
pointer.initialize (getNextRandomValue)
let cPointer = COpaquePointer (pointer)
let functionPointer = CFunctionPointer <() -> Int32> (cPointer)
To call a function through a pointer to it, do the following:
let newCPointer = COpaquePointer (functionPointer)
let newPointer = UnsafeMutablePointer <() -> Int32> (newCPointer)
let rNumber = newPointer.memory ()
I tried in the sandbox, having initially slipped the function written on the swift. In the last line, the function is executed. It would seem that the wines, but for some reason did not work in the program. The program compiles, the function pointer is created, the object to the notification is signed and received, but when received, the application crashes without error. Some kind of pointer is not quite qualitative, but it’s not enough to understand what my knowledge is.
In the C, it will have a CFunctionPointer <() -> Int32> type. To create CFunctionPointer, COpaquePointer is needed, eg:
let pointer = UnsafeMutablePointer <() -> Int32> .alloc (1)
pointer.initialize (getNextRandomValue)
let cPointer = COpaquePointer (pointer)
let functionPointer = CFunctionPointer <() -> Int32> (cPointer)
To call a function through a pointer to it, do the following:
let newCPointer = COpaquePointer (functionPointer)
let newPointer = UnsafeMutablePointer <() -> Int32> (newCPointer)
let rNumber = newPointer.memory ()
I tried in the sandbox, having initially slipped the function written on the swift. In the last line, the function is executed. It would seem that the wines, but for some reason did not work in the program. The program compiles, the function pointer is created, the object to the notification is signed and received, but when received, the application crashes without error. Some kind of pointer is not quite qualitative, but it’s not enough to understand what my knowledge is.
My decision
Wrote a class on ObjC. And when it was necessary to inherit - heirs on the Swift.
Let's move on to more general things. Speaking of Swift "fully compatible" [c ObjC], it should be kept in mind that all things from ObjC are accessible in Swift not directly, but through bridges. The simplest examples are: NSArray -> [AnyObject], NSDictionary -> [NSObject: AnyObject], and the Swift strings (String) seem to have functions from NSString, but again, not all (for example, length) are a bunch of global functions starting with objc_. And in most cases when transferring something from ObjC to Swift, we see AnyObject. I know the reasons, but now it’s not about them, but about the consequences. Of course, AnyObject is needed, as an opportunity, situations are different. But its use contradicts the ideology of the language a bit, because Swift is characterized by strong typing (which should increase the reliability of the code). And when using any frameworks from Apple, we see AnyObject everywhere in the functions, because they are all on ObjC. As a result, we must match the result of every second function from the standard library to the required type. And God forbid you do not guess or confuse what should be the type! [I know that you can do a check with is, but suddenly all the brevity and simplicity of the code disappears somewhere].
So, we are given a new, more reliable language, due to the fact that we are obliged to indicate the type of variables. But the functions of standard libraries often return non-typed objects. Of course, the condition of "full compatibility" is not violated, but at this moment I have a little jarring.
A similar situation, albeit in a lighter form, with optional variables. Optional variables may well be called language tools, but if you write in the style that Swift assumes, then you have to use them very infrequently. The functions of the NS classes return optional one. And it also makes change the programming style for the sake of compatibility.
[ deprecated in 1.2 ]
Let's go back to the details. There are things in the Foundation, which are still completely unavailable in Swift. For example, the NSDecimal class. Although the documentation had a description on the swift, it was impossible to use it. Thus, if in the ObjC function there was NSDecimal as an input or output parameter, you simply did not see it in the swift. And if they wrote, it was not compiled because of an error. However, if you believe Google, except for users of the Core Plot library (because of which I also encountered this problem), this class was not really needed by anyone. True, in 1.2 it can now be used. But this is something that only I encountered. And for sure, even in the comments there are other examples of inaccessible classes.
See for yourself, but I, considering all the above, when assessing the compatibility of Swift and ObjC, would rather use the words “almost complete”.
About convenience
I don't really like Objective-C. And I almost love Swift. According to the main page of Apple's Swift , this language is both innovative and modern. I will not argue with that, but according to my feelings, he has not yet grown to the point where they can be used painlessly. Some shortcomings are evident almost immediately when they get acquainted with the language, but some are not quite obvious. I will simply list everything that is in the way now, but I hope it will be corrected in the future.
[ deprecated in 1.2 ]
The first is the difficulty in debugging. While dictionaries and arrays in ObjC we could open and view directly in the debugger panel, standard swift classes cannot be opened and viewed. Debagger only shows their type. As I said, this concerns the standard classes, if you use NSDictionary or NSArray, they are expanded as before (it’s understandable, the Foundation is on ObjC). Alternatively, you can use NSLog, but this is obviously less convenient.
Similar to the previous situation with optional variables. Whatever the type, in the debugger you will see only nil this variable or some, and you will not achieve anything from it anymore.
Fixed in 1.2. And some, and classes swift now you can watch.
I don’t know what to call this situation, but the following happens: while analyzing the swift code in Xcode, something breaks, it gives an error about it and the whole syntax highlighting disappears. Then this is something, apparently, is restarted, the backlight appears again, and even autocomplete works again. But here these faults occur at the moment when the code is not compiled (for example, the bracket is open, etc.), and sometimes when I have not yet given the name of a variable or function. Although Xcode does not crash, and that is good, but nevertheless, all this does not look very elaborated.
String - standard swift language class. It has an automatic bridge to NSString. However, the length function does not have. I know that there is a reason for this, but the fact remains: such a simple function like the length of a string is made more difficult in Swift.
Options
The global count function (until very recently, countElements). Only it is not in the online documentation (about which later), but someone can tell you about it. count (string)
Function .utf16Count. It does just what you would like to make a .length function, the name looks almost intuitive too. Example: string.utf16Count
Removed in 1.2. Xcode suggests replacing with count (string.utf16).
endIndex - the index of the last character. But is the type of String.Index, to get an Int will have to suffer. string.endIndex
caste in NSString and use .length: (string as NSString) .length
Function .utf16Count. It does just what you would like to make a .length function, the name looks almost intuitive too. Example: string.utf16Count
Removed in 1.2. Xcode suggests replacing with count (string.utf16).
endIndex - the index of the last character. But is the type of String.Index, to get an Int will have to suffer. string.endIndex
caste in NSString and use .length: (string as NSString) .length
Very special case. objc_setAssociatedObject takes as its last parameter a type parameter - typealias objc_AssociationPolicy = UInt. Next to the type, variables are defined that define this policy OBJC_ASSOCIATION_ASSIGNb, OBJC_ASSOCIATION_RETAINb, OBJC_ASSOCIATION_COPY, etc., and they are of type Int. Why? Why should I explicitly lead and write 2 times longer: write objc_AssociationPolicy (OBJC_ASSOCIATION_COPY)? I hope someone will explain (comments ?!)
About variability
Swift is a new language, even from the moment of the announcement, even a year has not passed. It is actively developing, which is good news, and it is changing, which makes you think a bit. And sometimes, changes can significantly change the programming style, for example, before the constants had to be assigned immediately upon declaration, and from version 1.2 - after. Others are just a syntax change (countElements -> count). Literally at the time of writing this text I updated Xcode (remember, version 6.3 was released on 04/04/15 and contains a new version of swift 1.2), and now the project is not compiled. Almost everything as asks to be replaced with as!, Well, it is clear from the description of changes to the new version. But the unobvious change: NSDictionary is now for some reason not automatically converted into [NSObject: AnyObject], like NSString in String, and NSSet -> Set, and NSArray -> [AnyObject] is also no longer, well, you understand how works. And before that. And now - no. There are certainly good reasons for this, but I'm not talking about them now. Reverse assignment, by the way, still works without an explicit cast.
Xcode has a function for migrating to the latest version of SWIFT. In my experience update, alas, does not work as it should. All inconsistencies of the new version were removed only after the third carrying out of this operation (previous times also worked, but not all were removed), but as a result, the code did not become compiled. In one place, the utf16Count function remained uncorrected, although before the first conversion, Xcode offered an autochange, which now had to be replaced manually. That is, I had to do the conversion 3 times, because each time he did only part of the replacements, and then also edit the code in one place manually. I'm afraid to imagine the inconvenience experienced in large projects. Fearing a similar situation, I didn’t want to update Xcode before the project was completed, although the update was already officially released. Here is an indicative situation with updates.
And I’ll also briefly mention the undocumented global functions, which, in my opinion, are also a sign of the youth of the language: countElements, dropFirst, dropLast, first, last, prefix, suffix, reverse. So take a playground and try.
Conclusion
Debag already finalized, NSDecimal appeared. This is from the corrected deficiencies, in the list of changes 1.2 there are, of course, other improvements. It is seen that the work on the language continues to be actively. And I have no doubt that over time, and other shortcomings correct, and add chips. But there is a "but." Foundation no one will rewrite: ObjC is not going anywhere. In the meantime, all the core libraries are written in ObjC, Swift cannot be written in the style for which it was designed, since you will always need to interact with ObjC. Well, I hope to someday see a new framework designed specifically for SWIFT. It sounds fantastic, but if Apple plans to complete the transition to Swift, then I guess it will happen sooner or later. After all, there is the Core Foundation, and there is the Foundation.
I invite to discussion.
Source: https://habr.com/ru/post/256307/
All Articles