Show HN: NSString + Ruby

[dennis_vartan]

Like! Much as I love ObjC, reducing verbosity via better syntax can go a long way to making code more readable.

For example, I ended up putting together some defines like this after building a bunch of UI programmatically.

  #define RGB(r, g, b)     [NSColor colorWithDeviceRed:(r)/255.0 green:(g)/255.0 blue:(b)/255.0 alpha:1]
  #define RGBA(r, g, b, a) [NSColor colorWithDeviceRed:(r)/255.0 green:(g)/255.0 blue:(b)/255.0 alpha:(a)]

RGB(255, 104, 0) may be a bit too C-ish, but it sure beats the long form. Have similar GRAY(x) and GRAYA(x) defines for producing grayscale colors.

Definitely interested to see more projects along these lines.

[wrl]

I prefer:

    #define RGB(color)                        \
        (((color & 0xFF0000) >> 16) / 255.f), \
        (((color & 0x00FF00) >> 8) / 255.f),  \
        (((color & 0x0000FF)) / 255.f)

Pass in an HTML-style color hex triplet.

[cheesylard]

    #define RGB(r,g,b) RGBA(r,g,b,1)

[bennyg]

I wrote a utility class with idiomatic Obj-C color methods like the one you mentioned and more. I hate to plug it, but I'm fairly proud of it. It also generates color schemes when you throw a UIColor object at it, and includes 100 different UIColor generics like [UIColor seafoamColor].

https://github.com/bennyguitar/Colours-for-iOS

[numo16]

I use a few like this in some of my helper macros[0] that I usually pull into my iOS projects.

[0]: https://gist.github.com/numo16/3407652

[stefan_kendall]

I use the same thing to construct NSDecimalNumber instances. N(100.5) instead of [NSDecimalNumber decimalNumberFromString:@"100.5"]

SO handy.

[jakobe]

One thing that irks me is that the author doesn't stick to ObjC naming conventions.

Take for example the capitalize methods. In ruby, you have "capitalize" and "capitalize!" to distinguish the immutable and mutable versions. To make this distinction in ObjC, you generally use nouns vs. verbs. So for the equivalent of ruby's "capitalize", you'd use "capitalizedString" (which is in fact provided by NSString). But the mutable version, the equivalent of ruby's "capitalize" should simply be "capitalize", not "capitalizedStringInPlace".

[thingsdoer]

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

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

[khangtoh]

What's stopping you from submitting a pull request with these suggestions?

[chrisdevereux]

They look like convenient additions... but I'd be reluctant to add so many category methods onto a Foundation class. Especially for un-prefixed methods.

If a future version of iOS adds an -sum method, for example, you'd better hope it has the exact same semantics as yours, otherwise if the system calls -sum expecting its implementation to be used, bad things (or worse, bad things with no apparent cause) will happen when your implementation is used instead.

[thingsdoer]

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.

[jph]

Super! Are you motivated to do more like this?

I'll donate $100 to you if you want to continue with NS+Ruby classes.

[thingsdoer]

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.

[w0rdson]

I have to add the obligatory pitch for just using RubyMotion. I use it/love it, and def recommend it for those that have become a bit annoyed with the verbose-ness of obj-c.

[danenania]

I love the idea of RM and would like to give it a try, but I keep hearing murmurs about memory management issues and other little glitches that crop up from time to time. I also hear that these kinds of problems get fixed very quickly, but the idea of being stuck even for a short time while waiting for a proprietary abstraction to be patched up makes me a bit hesitant to reach for it for a serious app. Are these concerns overblown?

[andrewgross]

A friend of mine made NSArray extensions with a Ruby syntax a while back. Certainly useful if you find these helpful.

https://github.com/nsantorello/nsarray-extensions

[sarreph]

This is awesome and, as an Obj-C dev, is yet another thing that makes me want to learn Ruby.

[masklinn]

Good, I was worried people could actually be able to correctly manipulate text through NSString, that fixes it as it's impossible to not break text when using Ruby strings.

[thingsdoer]

>> hn.txt

[pdenya]

Very impressive. I didn't know about objectAtIndexedSubscript and objectForKeyedSubscript so I wouldn't have thought this was possible as a category.

[fleitz]

Almost everything is possible via a category though a lot of it involves hackery with objc/runtime.h

[hamxiaoz]

Is 'category' like a extension method in c#?

[fleitz]

Yeah, except you can add properties, though you have to do it with objc_(s|g)etAssociatedObject

https://developer.apple.com/library/ios/documentation/Cocoa/...

[YoyosForUs]

Wow, this looks really useful. Thanks for building this!

[mamcx]

Add a String format one, then is set!

[thingsdoer]

Still don't have a clever implementation.

[misiti3780]

hell yes - im a python guy but this still looks great!