Neat! Where did you get the data?

IMDb has a data dump: http://www.imdb.com/interfaces

It's kinda a mess to parse through it and get the data in though.

That data dump is a mess! I used it for my soundtrack project: http://thesoundtrackdb.com

Cool project! By the way, small correction: It should be courtesy, not couretsy.

Definitely. I only parsed through the names, ratings, and years. Going back to parse more stuff such as the number of votes, genre, etc. is going to be the most painful part of this project.

Whoa, I never knew imdb put their file as a dump. I've always tried to go through freebase

>> hn.txt

-(NSString*)capitalizeInPlace; is the actual signature.

The reasoning for this is for consistency, while still maintaining autocomplete proximity.

I'm not really sure I understand; why would calling the method "capitalize" instead of "capitalizeInPlace" be inconsistent?

(Also, the comments in the header file and the README file contain the name "capitalizedStringInPlace" instead of "capitalizeInPlace")

Another inconsistency is that most mutating methods in ObjectiveC don't return self, but either void or a boolean or an integer that reports if the method succeeded. But I assume that this inconsistency is on purpose because you want to make the methods chainable.

The issue with the default syntax in NSString is that the mutating methods are the more concise, but are also the ones you use the least. It makes far more sense for the more used methods to be more concise than their mutating siblings.

I don't disagree with you though. I'd prefer if the interface for this was more idiomatic.

Returning void is sort of pointless. A boolean, maybe. I feel like returning self is just making better use of things, really, and probably doesn't really cause any confusion.

Okay, now I get it, the naming makes autocomplete more convenient.

Returning void makes it easier to spot errors. If you accidentally use "capitalizeInPlace" instead of "capitalizedString" your code will compile without issues. If the mutating method returned void, it would result in a compile error.

That's an extreme edge case though, since if you're using a mutating method, you're using a mutating string, and you're probably aware of that.

There are already a lot of Ruby categories out there. ObjectiveSugar covers a lot of bases. I personally wouldn't import more Ruby categories. The NSString API is a weak point of Cocoa, IMO, but in general I wouldn't like to see a large amount of unique, dependent, astonishing code.

ObjectiveSugar: https://github.com/mneorr/ObjectiveSugar

Awesome! I hadn't seen this.

Still don't have a clever implementation.

Unfortunately, although there's no particular reason for it, you're not allowed to write a method that takes only variadic arguments. This doesn't work:

    - (NSString *)format: ...;

It would be oh-so convenient, meaning you could write formatting operations like this:

    newstr = [@"%d %@ %s" format: 42, @"blah", "yep"];

Given the constraints we have to work with, I'd say your best bet would be to simply write a function:

    newstr = fmt(@"%d %@ %s", 42, @"blah", "yep");

Comedy option:

    - (NSString *)format:(id)first, ... {
        NSUInteger argCount = 0;
        BOOL prevPercent = NO;
        for (NSUInteger i = 0; i < [self length]; ++i) {
            unichar c = [self characterAtIndex:i];
            if (prevPercent && c != '%')
                ++argCount;
            prevPercent = c == '%';
        }

        NSMutableArray *argArr = [NSMutableArray new];
        va_list args;
        va_start(args, first);
        for (NSUInteger i = 0; i < argCount; ++i)
            [argArr addObject:va_arg(args, id)];
        va_end(args);

        switch (argCount) {
            case 0: return [NSString stringWithFormat:self, first];
            case 1: return [NSString stringWithFormat:self, first, argArr[0]];
            case 2: return [NSString stringWithFormat:self, first, argArr[0], argArr[1]];
                // ...
        }
    }

Only supports NSObject arguments, obviously. If you actually wanted to do this approach you'd want to do a better job of parsing the format string and use a more cleverer way of storing the args.

Or, for the completely insane approach that probably doesn't actually work (on top of being entirely unportable):

    - (NSString *)format:(id)first, ... {
        NSUInteger argCount = ...;

        va_list args;
        va_start(args, first);
        void *argList = malloc(sizeof(id) * (argCount + 1));
        memcpy(argList, (void*)&first, sizeof(id));
        memcpy(argList + sizeof(id), &va_arg(args, void *), sizeof(id) * argCount);
        va_end(args);

        NSString *ret = [[NSString alloc] initWithFormat:self arguments:argList];
        free(argList);
        return ret;
    }

Why not just have it be a static method like stringWithFormat?

  + (id)stringWithFormat:(NSString *)format, ...;

This of course already exists, but if you wanted to do a Rubyfied version of it, then just follow the same general pattern.

The problem people have with the format implementation is that no matter what you do, it's either obtuse shorthand, or incredibly verbose.

The reality is, that NSString needs native formatting sugar. Anything else would really just be a hack. I'm not particularly even happy with the [@"Hello ":@"World] syntax, either.

Here's a crazy idea:

    newstr = [@"%d %@" format 42, @"blah"];

Implement it as a method that takes a dummy parameter, plus a macro:

    - (NSString *)format:(int)dummy, ...
    #define format format:0,

Awful way to do it, but the resulting syntax is not entirely terrible.

I'm not super comfortable with breaking message syntax like that. Also, very wary of using a #define with a short oft used keyword in a library that will be imported in majority of headers.

Exactly I just want this:

  NSString *newS = @"blah " + @(42) + @"!";

Unfortunately, something like "fmt()" isn't really elegant enough, or "objective-c" enough.

I'd correct the category. Also, NSString is not going to change. If it does, it will be rewritten extensively, most probably obsoleting this category.

Methods are often added to core classes like NSString. For example, in iOS 6: https://developer.apple.com/library/ios/releasenotes/General...

And you changing the category won't help the versions already out in the wild. Hopefully, automatic updates will mitigate this to some degree but not everyone will turn them on.

There are workarounds (like prefixing methods with a pseudo-namespace), but they're all a bit ugly. Might be worth considering though.

Actually, I might add some protection around this specific case.