Ok cool, but where's the source code? It's been almost three months since the announcement and no ones even mentioning it anymore.
Swift 2 Apps in the App Store
21–30 of 33 posts
Re: Swift 2 Apps in the App Store
#22I ran the “Convert > To Latest Swift Syntax” on an app with about six view controllers, four views, a network service, and three cocoapods. It worked surprisingly well, most of the changes were really just suggestions ("this var something could be a let something"), small change to how NSData unwraps. I did have to guess around an obscure compile issue (solution: "Clean Build Folder"), but after that it was clear sai…
I really like Swift too, but for serious usage, I find that it still gets kinda wonky in generics land. Also, not crazy about the fact that there's no such thing as abstract classes. A lot of iOS coding for me is stuff that builds on top of each other. You can subclass, but there's so many times when it's "all subclasses gotta just do this one or two things and base class can take care of rest." So what you do is def…
Protocol extensions seem like a good way to get what you'd frequently want out of abstract classes. What's missing?
Re: Swift 2 Apps in the App Store
#23Ok cool, but where's the source code? It's been almost three months since the announcement and no ones even mentioning it anymore.
This was ask on Reddit recently, and Chris Lattner answered:
https://www.reddit.com/r/swift/comments/3kbjjn/so_swift_isnt...
We are still on track to open source Swift (including Linux support) "by the end of 2015" as promised, more details will come out when they can.
-Chris
Re: Swift 2 Apps in the App Store
#24Earlier quoted context omitted.
I really like Swift too, but for serious usage, I find that it still gets kinda wonky in generics land. Also, not crazy about the fact that there's no such thing as abstract classes. A lot of iOS coding for me is stuff that builds on top of each other. You can subclass, but there's so many times when it's "all subclasses gotta just do this one or two things and base class can take care of rest." So what you do is def…
Protocol extensions seem like a good way to get what you'd frequently want out of abstract classes. What's missing?
What I want (Scala land):
trait Robot
var serialCode = generateSerialCode()
def gas
def engine = Engine(gas)
def body = Body(engine)
class SunnyRobot extends Robot
def gas = sun
class OilyRobot extends Robot
def gas = oil
* `extension Robot where Self = SunnyRobot { def gas() = ... }`
* `extension Robot where Self = OilyRobot { def gas() = ... }`
That looks all good and well, right? Ok, well now my sunny robot wants to find the sun and my oily robot wants to go find oil. How to provide functionality unique to each of them? Maybe I'm just not getting something, but I'm pretty sure protocol extensions are not the answer to the problem I'm trying to describe.
When you're working in front-end land, you can do your best to stay functional and be cool and all that jazz, but it's just a waste of time usually. You're going to use a lot of state and you just have to learn how to manage that effectively (IMO). What this boils down to for me is that I might build a cell that does 3 things great and will be on every cell, but then business designs call for 2 slightly different cells still based upon that main cell. Oh and when those different cells are tapped, different things should happen.
So again, I just go about doing it with the simple base class gonna throw you an exception unless you override the "abstract" method. This way, I get to keep state going down and classes can actually fill up naturally rather than playing the protocol game.
Re: Swift 2 Apps in the App Store
#25Swift 2 is fantastic except (har har) for exceptions. Optional has been hanging out, monad-y and all, since v1. Why not Result ? You can't flatMap exceptions, and the Swift 2 implementation even throws away type data (or hides it, at least). Huh?
There are no exceptions in swift.
Re: Swift 2 Apps in the App Store
#26Earlier quoted context omitted.
Or for those who prefer automating, add this to ~/.bash_profile: alias nuke="rm -rf ~/Library/Developer/Xcode/DerivedData/"
I always advice people to put their DerivedData and build folder somewhere accessible. You can change it settings, don't use the default setting.
Good tip. As someone with quite a small main HDD I'll do this ASAP.
Re: Swift 2 Apps in the App Store
#27Earlier quoted context omitted.
Protocol extensions seem like a good way to get what you'd frequently want out of abstract classes. What's missing?
What I want (Scala land): trait Robot var serialCode = generateSerialCode() def gas def engine = Engine(gas) def body = Body(engine) class SunnyRobot extends Robot def gas = sun class OilyRobot extends Robot def gas = oil Protocol extensions don't hold state. They are meant to provide default implementations for a type, not as a 1:1 relationship with the class it's implementing functionality for. Following what you'r…
Wouldn't you define gas() and whatever class-specific methods in the class itself, instead of in extensions on the protocol?
class SunnyRobot : Robot {
func gas() { ... }
func findSun() { ... }
}Re: Swift 2 Apps in the App Store
#28Swift 2 is fantastic except (har har) for exceptions. Optional has been hanging out, monad-y and all, since v1. Why not Result ? You can't flatMap exceptions, and the Swift 2 implementation even throws away type data (or hides it, at least). Huh?
I guess you mean the new do-try-catch syntax? IMO it's quite lovely, and strikes exactly the right balance between the checked exception tyranny of Java, and the strap-in-and-good-luck wild west of C++.
My favorite feature of Swift's exceptions is the 'try' syntax required at the call site. This isn't like Java's try syntax: every call that may raise an exception needs a try, even if all you want to do is rethrow the exception. But the syntax is lightweight: just preface the call with 'try', it doesn't make a new scope. This makes the abnormal control flow explicit, addressing one of the strongest critiques of Java-style exceptions.
My second favorite features is the 'try!' syntax. This is the escape hatch: Swift's version of the empty-catch-block pattern of Java, except that it's 1. much more lightweight, because it doesn't introduce a new scope, and 2. the default behavior is to abort instead of swallow. It's perfect for non-production code like tests.
Regarding "you can't flatMap exceptions," I would respond that exceptions are meant to be exceptional, and this is what justifies the abnormal control flow. The do-try-catch syntax is an adequate substitute for flatMap, and more lightweight than requiring explicit unpacking of every return value ala Go.
But as you say, the hiding of type data is definitely weird. For those following along at home, Swift requires explicitly annotating functions that may throw errors, but not what those errors are, so you have to refer to the documentation. Also the compiler will complain if you don't have a backstop exception handler. Lastly, it introduces a magic variable 'error' that is defined within catch blocks: convenient but it feels ad-hoc.
Re: Swift 2 Apps in the App Store
#29If your Swift app is using SpriteKit it might take a little longer to get it ready for the App Store: https://forums.developer.apple.com/thread/17463 Apple really screwed up SpriteKit badly in the new version. I'm experiencing almost all of the problems mentioned in the forum.
I scanned the post and it seemed the issues are regardless of the language.
That's true. I didn't want to badmouth swift, I quite enjoy developing with it. I guess I just needed to vent my anger about SpriteKit a little.
Re: Swift 2 Apps in the App Store
#30Earlier quoted context omitted.
What I want (Scala land): trait Robot var serialCode = generateSerialCode() def gas def engine = Engine(gas) def body = Body(engine) class SunnyRobot extends Robot def gas = sun class OilyRobot extends Robot def gas = oil Protocol extensions don't hold state. They are meant to provide default implementations for a type, not as a 1:1 relationship with the class it's implementing functionality for. Following what you'r…
Wouldn't you define gas() and whatever class-specific methods in the class itself, instead of in extensions on the protocol? class SunnyRobot : Robot { func gas() { ... } func findSun() { ... } }
By defining `gas()` in the children, you can't take advantage of it in base class. For example, the base robot might know how to move and all that, but the sunny robot just needs to know where it's going.
Protocol extensions just don't cut it, I'm sorry. They're great for defining some default behavior and doing kinda-abstract-classes, but it's a different playing field in Swift/Obj-C than Java/Scala/C#/etc..