thingsdoer

Neat! Where did you get the data?

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.

>> hn.txt

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.

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

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

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.

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.

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.

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

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

Still don't have a clever implementation.

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.