equivalent to @Named injections

[doug-w]

It would be interesting if a module could add an NSDictionary to an injector and have a new macro that maps keys in that dictionary to properties.

Something like:

@interface MyModule : JSObjectionModule
@end

@implementation MyModule
-(void) configure
{
    [self bindNames:@{@"NamedProperty" : @"This will be a named Property"}];
}
@end

@interface MyObject
@property (weak, nonatomic) NSString* myProperty;
@end

@implementation
objection_requires_names(@{@"NamedProperty" : @"myProperty"})
@end

While not needed it would be nice to have a convience method that would load a plist like that.

[jdewind]

Interesting idea. You can statically declare NSDictionary data structures? I thought NSString's were still the only place where that was supported.

[doug-w]

Objective-C has had object literals since mid 2012 (Clang 4, XCode 4.4, not
sure if gcc ever got it.) @{key:value} NSDictionaries, @[obj2, obj2]
NSArrays, @yES BOOLs, @(2) autoboxing integers, @(nullTerminatedCString)
autoboxed C String to NSString etc..

As for the @nAmed, I keep meaning to play with it, I think I'd like to
separate out the equivalent of properties vs named injected it'd be nice to
support both so that you could have something like:

@Property (weak, nonatomic) FileIOType* configFile; // Gets a singleton
FileIOType that's bound to the config file
@Property (strong, nonatomic) FileIOType* writerFile; // Gets an instance
of a FileIOType

objection_requires_names(@{"FileIO.configFile": @"configFile"}); which
internally would be binding the key to a provider.

If I get the time I may float a prototype for feedback.

On Mon, Mar 3, 2014 at 8:00 AM, Justin DeWind [email protected]:

Interesting idea. You can statically declare NSDictionary data structures?
I thought NSString's were still the only place where that was supported.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-36524229
.

[jdewind]

I understand that it has had literals. But my understanding is that they can not be used statically.

[jdewind]

Actually, concern about the structured being available statically is irrelevant. They are passed to a macro that generates a selector. The context would never be static.

[sethew]

A dictionary can be passed to a macro, but the syntax is a little unusual, as it requires double parentheses:

objection_requires_names((@{@"LeftHeadlight":@"leftHeadlight", @"RightHeadlight":@"rightHeadlight"}))

I have written an implementation of named bindings. It does not handle config files, but it will allow for separate bindings for dependencies of the same class or protocol. I'll submit a pull request, but I'd appreciate any feedback before accepting it.