Swift 2 Apps in the App Store • Hacker News Board

Re: Swift 2 Apps in the App Store

#31

Post by joslin01 » Tue, Sep 22, 2015, 11:34 AM UTC

allsystemsgo wrote: post #15

Eric_WVGG wrote: post #2

I 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…

That's a pretty small app. Sure, it's ready for smaller apps but, things aren't so great on larger scale apps.

This was being down-voted for no reason. He's right..

Re: Swift 2 Apps in the App Store

#32

Post by jayrhynas » Tue, Sep 22, 2015, 3:47 PM UTC

joslin01 wrote: post #30

jayrhynas wrote: post #27

Earlier quoted context omitted.

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..

I think this[1] does what you want, unless I'm not understanding your problem description. AFAIK you are correct about protocol extensions not holding state. So I don't think you can implement the `var serialCode = generateSerialCode()` with just a protocol. But you could do it with a protocol + base class.

[1]: https://gist.github.com/jayrhynas/49945331e41314fc3ede

Edit: I just realized that with this method, the protocol extension is useless, you could just define `move` on Robot. So protocol extensions can give you a mix of abstract & default methods but if you need to inherit state you need to use a base class.

Re: Swift 2 Apps in the App Store

#33

Post by gorena » Tue, Sep 22, 2015, 8:46 PM UTC

ridiculous_fish wrote: post #28

gorena wrote: post #18

Swift 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…

Well, for example, try/catch don't work asynchronously, so you can't pass it to a callback (or use it in a SignalProducer in RAC). If failure/success is Just Another Value, it works everywhere that values work. That they already use an ADT for nullability it what confuses me - ".None, but with an error" isn't a far off concept from that.

antitypical/Result already provides Result.init(() throws -> T) -> Result, so it's easy enough to work around, at least.

The magic variable stuff exists in didSet as well, weird and sketchy to use. Would prefer it to be explicit in all cases.