Use protocol for assembly interface?

[jasperblues]

There are two arguments for using a protocol for the assembly interface:

• For the 'proceeding from one object graph to another' use-case (ie ViewControllerA->ViewControllerB), we can inject the TyphoonComponentFactory posing as this interface. This way there is no direct dependency on Typhoon. . currently there is an (albeit loose) dependency on Typhoon, since we're injecting something that derives from TyphoonAssembly.
• (Not proven): We could boostrap a Swift application using both the plist or manual approach. In Swift if you start with a TyphoonComponentFactory and then tell it to pose as an assembly interface the result is an EXC_BAD_ACCESS. Fortunately this doesn't happen when injecting the TyphoonComponentFactory into other components (hence plist boostrapping works).

Arguments against:

It would make the assembly more verbose. Objective-C style would look something like this:

File: MyAssembly.h:

@protocol MyAssembly

- (Knight*)knightWithSupernaturalPower:(id<Supernatural>)power;

- (Quest*)quest;

@end

File MyAssemblyImpl.m:

(perhaps no need for a MyAssemblyImpl.h, unless this seems odd)?

@interface MyAssemblyImpl<MyAssembly>
@end

@implementation MyAssemblyImpl

//definitions

@end

For Swift there's also the advantage of having a clean interface that serves as 'blackbox' documentation.

[alexgarbarev]

I belive it's the only way to get swift working assembly interface without force casting.

Since we cannot cast TyphoonDefinition into type of object buileded by definition, we cannot write code something like:

public dynamic func service(runtimeText: NSString) -> MyService {
    return TyphoonDefinition.withClass(MyService.self) { (definition) in
        definition.injectProperty("text", with: runtimeText) as MyService
    }
}

We must write definitions which returns AnyObject:

public dynamic func service(runtimeText: NSString) -> AnyObject {
    return TyphoonDefinition.withClass(MyService.self) { (definition) in
        definition.injectProperty("text", with: runtimeText)
    }
}

But this cause us to do casting in client code (using assembly interface):

let service = self.assembly.service("runtime argument") as MyService

I think it's acceptable. Not a big problem.. In objective-c we spefy object type anyway, when declaring variable

MyService *service = [self.assembly serviceWith:@"runtime argument"];

So I think it's ok for Objective-C Developers.
But for those who like Swift automatic type detection: just declare protocol which assembly methods:

@objc protocol Assembly {
    func service(runtimeText: NSString) -> MyService   
}

Then use this protocol for assembly injected property:

var assembly: Assembly

And client code becomes to:

let service = self.assembly.service("runtime argument")

Swift detect return types and work great. Also, as you mention, assembly protocol can be black-box documentation for those who not familiar with typhoon - clear 'factory' protocol
But this can be boring: sync changes in assembly and their interface.
Another problem is that we cannot use injection by-type for these properties. (Maybe we can register assembly protocols somewhere to get this working). Currently assembly injection looks like:

public dynamic func appDelegate() -> AnyObject {
    return TyphoonDefinition.withClass(AppDelegate.self) {
        $0.injectProperty("assemblyInterface", with: self) // <-- explicit 'self' injection as assembly protocl property
    }
}

[jasperblues]

Closing. . its optional for the user.