Not possible (AFAIK) to call [TyphoonAssembly assembly] from Swift.

[ghost]

According to this Stack Overflow post it should technically be possible, but I think maybe [TyphoonAseembly assembly] is colliding with [TyphoonAssembly init].

[jasperblues]

You're right, when calling TyphoonAssembly() from Swift it goes direct to the (private in ObjC) init method. And there was actually some additionally config being done in the 'assembly' method, causing problems in Swift.

This has been fixed (additional config moved), but not yet pushed to CocoaPods. Meanwhile to use:

pod 'Typhoon', :head

Verify ok?

Current state of Swift:

• Create components with TyphoonAssembly sub-class.
• Resolve them via TyphoonComopnentFactory (componentForKey, compnentForType, etc)
• You can't yet resolve components using the assembly interface. Swift's strict typing doesn't like this.
• Runtime args haven't been tested. We might have problems here too.

[ghost]

Thanks. I'll give it a shot today. I was seeing some issues with runtime args yesterday as well, but I couldn't tell if it was a Typhoon issue or my own. I'll report back after trying with "pod 'Typhoon', :head".

[ghost]

I had a chance to try out the latest with Swift. Here are my results:

• Was able to create assemblies and instantiate them into a TyphoonBlockComponentFactory (with caveat).
• Was able to use TyphoonStoryboard to inject Assembly properties into my UIViewControllers (again with caveat).
• Was not able to use run-time args injection.

The main issue I faced (other than run-time args) was with property injection. This occurred both in my client classes (e.g., UIViewControllers, etc.), and inside assemblies using the interface of other assemblies. The issue has something to do with optionals, I think. Currently, I have two assemblies in my project: Services and Controllers. Inside Controllers, I want to use the Services assembly, so I have a property declaration:

var services: Services?;

If I do it this way, I get an exception inside objc_msgSend_InjectionArguments (TyphoonAssemblyDefinitionBuilder.m) at line 186.

The workaround is to not use an optional, but rather assign a dummy value that gets thrown away:

var services: Services = Services();

Edit: Upon second look, I'm not sure that this workaround actually does what I want it to. It doesn't crash, but I'm not certain that the property is being replaced with the appropriate assembly by the factory. I'm just using [TyphoonComponentFactory makeDefault] as a workaround for now.

Are you aware of any workaround for the run-time args issue? Thanks.

[ghost]

Oh, I also had to make sure that any class I'm trying to inject into derives from NSObject.

Should I open separate issues for any of this stuff?

[jasperblues]

That's the expected behavior. If you extend NSObject (or use the '@objc' derictive) then:

• The class will use dynamic dispatch for method invocation.
• Introspection (aka reflection) is enabled.

Otherwise:

• The class will use static/vtable dispatch
• There is no reflection whatsover execept for a simple Mirror protocol that simply describes properties. (Not enough for DI).

. . . we we're waiting to see if the latter case is a work in progress or if the intention is that these classes without a base will be C++-style lean. (C++ also has static dispatch and no reflection).

(ie another way to ask that question is: Is the ObjC runtime just for interop with legacy, or will it remain as the runtime).

Depending on the outcome we'll either:

• Write a new instance builder for 'pure' Swift classes.
• Recommend you do extend NSObject or turn on the ObjC runtime.

[jasperblues]

Typhoon 2.1.2 (released) yesterday 'fixes', not being able call [TyphoonAssembly assembly] from Swift

• [TyphoonAssembly assembly] now calls [[alloc] init] and nothing else.