I'd love some feedback from anyone, especially Jasper and other Typhoon collaborators
Great work Jeff. Looks good.
Its nice to see an example of Typhoon with Swift 2. . . one of the features users have had trouble with is with Swift 2 style exception handling. Did you have develop any recommended standard approach for that with Typhoon?
I had a number of problems related to Typhoon and Swift 2, all of which stem from trying to inject classes/protocols that could not be annotated as @objc or subclass NSObject and therefore could not participate in Dependency Injection in the normal way. I did not encounter any issues with Typhoon in regards to throwing functions. I did design API's using "throws", but did not reference any of them in Typhoon. Are you referring to invoking failable initializers or calling throwing functions from Typhoon?
For code I could control since I wrote it, I chose not to change my API so that the classes could participate in Dependency Injection in the normal way. One of the protocols in one of the frameworks I wrote that is used by the app is this : https://github.com/JeffBNimble/swift-protocols-sqlite/blob/master/SwiftProtocolsSQLite/database/SQLiteDatabase.swift. Notice all of the throws functions. Because of those, Swift 2 cannot represent this protocol as an Objective-C protocol. I chose not to convert my API since I designed it with throws in the first place. This led to Typhoon problems.
Develop a new framework that uses compile-time instrumentation rather than runtime.
For the most part, Typhoon worked as it should. For the Objective-C version of the app, I was able to do everything I needed and not have to make any changes due to limitations in the language. However, with Swift 2, that was not the case. I encountered a handful of things I simply could not do with Typhoon. Again, not because of Typhoon, but because of Swift 2.
Sure, but I wouldn’t recommend Typhoon + Swift 2 as a good combo.
When Swift 1.0 came out we were concerned but hopeful the language would become more dynamic.
But it seems to be moving away from ObjC interoperability.
So the approach to DI will need to be different.
A solution based on the ObjC runtime seems to impose limitations