Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Injection with Run-time Arguments Fails with Swift String #324

Closed
dereekb opened this issue Feb 28, 2015 · 3 comments
Closed

Injection with Run-time Arguments Fails with Swift String #324

dereekb opened this issue Feb 28, 2015 · 3 comments

Comments

@dereekb
Copy link

dereekb commented Feb 28, 2015

Ran into a bug where when trying to inject with a Swift string instead of a NSString it results in a function call (Foundation._convertNSStringToString) to convert between types which results in the forwardingTargetForSelector: function of TyphoonInjectionByRuntimeArgument being called and crashing program.

Workaround is to instead declare the type as NSString:

public class Assembly : TyphoonAssembly {

//Causes crash
public dynamic func foo(boo:String) -> AnyObject { ... } 

//Safe
public dynamic func foo(boo:NSString) -> AnyObject { ... } 

}

If boo is declared as an NSString before injection, the conversion won't occur.

@jasperblues
Copy link
Member

Hello @dereekb,

I'm afraid this is a known limitation and I don't think there's anything we can do about it at this stage.

Swift doesn't have its own native reflection and by default it uses the less dynamic vtable style dispatch, in contrast to Objective-C's very flexible messaging. Therefore for DI with Typhoon we go via the Objective-C runtime, which can only deal with types that are interoperable between both layers.

@dereekb
Copy link
Author

dereekb commented May 29, 2015

Yea I figured as much. Just thought I'd report it incase someone else runs into the issue.

@jasperblues
Copy link
Member

Thanks @dereekb, we appreciate that. We put the information in the Swift Quick Start, but if you can remember the place where you expected to find this information (header doc, another wiki, etc) we can also add it there. . We'd much prefer folks to know about this up-front than to encounter the issue and then go searching for answers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants