* Obj-C, from the very start, was implemented as a strict superset of C. This means that every valid bit of C code must also be valid Obj-C. This places some rather sever limitations on the Obj-C syntax. Ruby does not have this limitation, and neither does RubyMotion. So one reason you might use RubyMotion is to get a cleaner syntax that does the same thing as Obj-C.
* The Obj-C runtime is very dynamic. You can create classes on the fly, add methods to them at runtime, move methods around between objects, and create methods dynamically. The Obj-C language makes it nearly impossible to take advantage of any of these features of the Obj-C runtime. So another reason you might use RubyMotion is to get the most out of the Obj-C runtime.
Edit: I obv. didn't write your parent comment. What I meant was that I'm sure others in my position, having read your parent, would appreciate more elaboration from you as well. :)
Here's how to create a property on the fly (great for categories)
@dynamic progressView;
- (void)setProgressView:(ACProgressView )progressView { objc_setAssociatedObject(self, ACProgressViewKey, progressView, OBJC_ASSOCIATION_RETAIN_NONATOMIC); }
- (ACProgressView )progressView { return objc_getAssociatedObject(self, ACProgressViewKey); }
NSObject obj = [NSObject init];
giveObjectAProperty(obj, @"progressView");
obj.progressView = [NSNumber 42];
And of course the parent is talking about methods, not properties, but...same argument.
Here's how you'd make that class on the fly:
Class mySubclass = objc_allocateClassPair([NSObject class], "MySubclass", 0);
static NSString *Description(id self, SEL _cmd){
return [NSString stringWithFormat: @"<%@ %p: foo=%@>",[self class], self, [self foo]];
}
// add Description to mySubclass
// grab NSObject's description signature so we can borrow it
Method description = class_getInstanceMethod([NSObject class],
@selector(description));
const char *types = method_getTypeEncoding(description);
// now add
class_addMethod(mySubclass, @selector(description), (IMP)Description, types);
class_addIvar(mySubclass, "foo", sizeof(id), rint(log2(sizeof(id))), @encode(id)); klass = Object.const_set "MySubclass", Class.new(Object)
klass.send(:attr_accessor, :foo)
klass.send(:define_method, "description") {
"<#{self.class}: foo=#{self.foo}>"
}[1]: https://github.com/mikeash/MAObjCRuntime [2]: https://github.com/mikeash/MACollectionUtilities
But the real payoff is threefold:
1) You can use and write very ruby-ish wrappers for things. A great example is teacup, which lets you essentially write stylesheets for your UIViews (and I guess now NSViews).
2) Working with collections like arrays and hashes is MUCH more convenient. You can spend a good part of your time doing just that.
3) Command-line toolchain. It's not for everyone, of course, but for those who work better like that, it's a revolution.
Right now it's pretty wild west. There's no obvious winner in terms of libraries for the data layer, for example. So taking on an RM project right now either means rolling up your sleeves and hacking on the infrastructure, or just living with raw Cocoa, without benefit of autocomplete. Give it another 6-12 months and I think you'll see a very strong contender.
> That means, no writing everything twice (header files,
> type declarations)
Your header files can be practically empty if you don't need to show something to outside. Just put your @property'ies into class extension. Even @synthesize no longer needed (most of the time, there are exceptions).
> Working with collections like arrays and hashes is MUCH
> more convenient. You can spend a good part of your time
> doing just that.
Cocoa is a fantastic system to build on top of. NSDate is MILES better than the Ruby time stuff, for example. NS/UI solid core plus Ruby's flexible syntax and culture of sensible defaults is a marriage made in heaven.
Well, there's a solid argument to be made in favor of limiting how much internals are exposed to other objects. I personally like keeping my headers as minimal as possible.
As for readability. Ruby is getting there but currently:
- (void)employersWithCarrierID:(uint)carrierID withMaxReturnCount:(uint)count;
[self employersWithCarrierID:123 withMaxReturnCount:10];
def employers (id, count)
employer 123 10`employer carrier_id: 123, max_return_count: 10` is very much valid ruby.
[1]: https://github.com/pandamonia/BlocksKit [2]: http://pandamonia.github.io/BlocksKit/Documentation/Categori...
RubyCocoa was actually a wrapper, but was very slow. MacRuby's innovation was that it was a Ruby implementation in Obj-C, but it relied on GC and was Mac OS X only. RubyMotion ditched the need for the GC and supports iOS and now Mac OS X.