Modernise ObjC, for better Swift compatibility. Bug fixes.

[DouglasHeriot]

Also added the sample project, rewritten in Swift.

Used Xcode’s Objective-C moderniser, and manually types to some NSArrays, and manually added nullability specifiers.

It’s the nullability stuff that mostly needs to be looked at carefully. Swift may crash if it gets a nil where it’s not expecting it. But if it assumes everything is nullable by default, writing code gets filled with lots of ? checking for nil.

[DouglasHeriot]

A few more updates. Includes a crashing bug fix, where it was possible to call a method on NSNull after failing to enter the correct passcode. c9ad6f28562b107642938a038464c4e2fb7ea6d0

I plan to continue working on this branch until it’s merged, cleaning up things as needed,

[ChrisAshworth]

Cool, thanks Douglas! Just to be clear, we are not currently planning moving any of our work to Swift for a while. It could be a long time before we make that transition; waiting at least until the language settles down.

[DouglasHeriot]

Yeah – I don’t think rewriting stuff in Swift for the sake of trendiness makes any sense. But for new projects, I think it has a lot of benefits.

These updates to QLabKit aren’t really Swift-specific in any way (except the 1 example file) – it’s just modernising with the newest Obj-C features. This brings increased safety and better warnings when compiling against other Obj-C code, and makes integration with new Swift projects heaps nicer.

It would be nice to see this merged so everyone can benefit, and I don’t end up maintaining a fork. Maybe my branch name is misleading.

[ChrisAshworth]

I agree it will be good to merge it; just gotta find the time I can review enough to make sure we're good for updating the various places we use F53OSC and don't get any unpleasant surprises. :-) Since it's a biggish set of changes that might delay it for a bit.

[gwsounddsg]

Once I learned the speed of Swift I was sold. https://www.primatelabs.com/blog/2014/12/swift-performance/

[ChrisAshworth]

The speed is a nice thing for the future but the language is changing out from under itself and very Not Done Yet and is not suitable for shipping a product yet.

(mobile)

On Feb 27, 2016, at 2:19 PM, gwsounddsg notifications@github.com wrote:

Once I learned the speed of Swift I was sold. https://www.primatelabs.com/blog/2014/12/swift-performance/

— Reply to this email directly or view it on GitHub.

[DouglasHeriot]

Added fix for bug #16

[balord]

Great work on all of this -- thank you! And thanks for your patience. I finally was able to go thru your whole pull request today and cherry-picked the majority of it and pushed the changes master just now.

I'm not familiar enough with Swift to evaluate the demo project, so I chose to omit those pieces from the official repo for now. Perhaps in the future we can revisit including those. I'm sure it's all great -- I'm just not comfortable vouching for that code at the moment.

If you have thoughts on the additional nullables that I added (or any of the other tweaks), be sure to let us know. Some additional ones seemed necessary to me, even if just for rare edge cases.

[gwsounddsg]

I've been building with QLKit with a Swift app. The biggest thing is that enum's in QLKit dont bridge to swift. There's a simple solution that's not a big deal.

[balord]

f5e6f2631c02ce26c966839fef24b0144ab93051 changed QLKCueContinueMode to use NS_ENUM(). I don't see any we missed, but let me know if there are others.