4 ms·

How is this : alert = UIAlertView._alloc \ ._initWithTitle _S("Hello"), :message, _S("I'm MobiRuby"), :delegate, nil, :canc

How is this : alert = UIAlertView._alloc \ ._initWithTitle _S("Hello"), :message, _S("I'm MobiRuby"), :delegate, nil, :cancelButtonTitle, _S("I know!"), :otherButtonTitles, nil alert._show supposed to be better than this ? alert = [[UIAlertView alloc] initWithTitle:@"Hello" message:@"I'm ObjC" delegate:nil cancelButtonTitle:@"I know!" otherButtonTitles:nil]; [alert show];

orta 14y ago
A lot of these things can be abstracted out, but I agree. I think the MacRuby syntax is significantly better for cocoa/uikit ruby. And considering the man who made macruby hasn't been active on it for a long time, I wouldnt be surprised to see him just pop out with something like this one of these days.
Tloewald 14y ago
My thoughts exactly. I've gotten used to obj-c over the years but it's still ugly to my eye. This is way uglier and I doubt I'll have a nice editor for it any time soon.
ashleyw 14y ago
Exactly. The problem with this and MacRuby is you're only really using the Ruby syntax. The idioms are still mostly the same, which IMO is what makes Ruby shine, not necessarily just the syntax.
- jeremymcanally 14y ago
  But you're not STUCK with that. You can write wrappers. Look at HotCocoa: that's Cocoa code that looks like Ruby. Even outside of that, though, there are a LOT of things that you can do with MacRuby a lot cleaner thanks to it being Ruby over its Objective-C counterpart. Try launching an external process, for example. It's 5-8 lines of code at the very least in Objective-C (and it's not as flexible), whereas it's 1-3 easy to read lines in Ruby, depending on how much control and feedback you want. I think as it matures, we'll see some wrappers that will make MobiRuby closer to what people are wanting to see from a Ruby-on-iOS solution; it's weird that you guys seem to have no vision for this sort of thing.
buff-a 14y ago
Because its actually: file.rb: require 'stuff' class foo def something alert = UIAlertView._alloc \ ._initWithTitle _S("Hello"), :message, _S("I'm MobiRuby"), :delegate, nil, :cancelButtonTitle, _S("I know!"), :otherButtonTitles, nil alert._show end end Instead of file.h #import <stuff> @interface foo -(void)something:(BOOL)what andthen:(CGRect)thisthing @end and then file.m #import <otherstuff> #import <yetmorestuff> #import "file.h" #import <oh shit is this in the right place?.h> #import <i think this is ok> #define SOME_HACK #import <this better come after that define up there.h> @implementation foo -(void)something:(BOOL)what butthen:(CGRect)thisthing { alert = [[UIAlertView alloc] initWithTitle:@"Hello" message:@"I'm ObjC" delegate:nil cancelButtonTitle:@"I know!" otherButtonTitles:nil]; [alert show]; } Fuck that. 1. Don't Repeat Yourself. Computer have more memory than 1986. 2. Don't forget to turn on warnings-as-errors, otherwise that code above will compile and then break because (of course you noticed) the method declaration doesn't actually match the declaration but the compiler doesn't care because its a brutal hack.
EzGraphs 14y ago
Definitely agree. The place where ruby syntax might shine a bit is in code that does not interact with the Cocoa/IOs specific libraries (e.g. doing calculation, parsing/manipulating strings).

orta 14y ago

A lot of these things can be abstracted out, but I agree. I think the MacRuby syntax is significantly better for cocoa/uikit ruby. And considering the man who made macruby hasn't been active on it for a long time, I wouldnt be surprised to see him just pop out with something like this one of these days.

Tloewald 14y ago

My thoughts exactly. I've gotten used to obj-c over the years but it's still ugly to my eye. This is way uglier and I doubt I'll have a nice editor for it any time soon.

ashleyw 14y ago

Exactly. The problem with this and MacRuby is you're only really using the Ruby syntax. The idioms are still mostly the same, which IMO is what makes Ruby shine, not necessarily just the syntax.

jeremymcanally 14y ago
But you're not STUCK with that. You can write wrappers. Look at HotCocoa: that's Cocoa code that looks like Ruby. Even outside of that, though, there are a LOT of things that you can do with MacRuby a lot cleaner thanks to it being Ruby over its Objective-C counterpart. Try launching an external process, for example. It's 5-8 lines of code at the very least in Objective-C (and it's not as flexible), whereas it's 1-3 easy to read lines in Ruby, depending on how much control and feedback you want. I think as it matures, we'll see some wrappers that will make MobiRuby closer to what people are wanting to see from a Ruby-on-iOS solution; it's weird that you guys seem to have no vision for this sort of thing.

buff-a 14y ago

Because its actually: file.rb: require 'stuff' class foo def something alert = UIAlertView._alloc \ ._initWithTitle _S("Hello"), :message, _S("I'm MobiRuby"), :delegate, nil, :cancelButtonTitle, _S("I know!"), :otherButtonTitles, nil alert._show end end Instead of file.h #import <stuff> @interface foo -(void)something:(BOOL)what andthen:(CGRect)thisthing @end and then file.m #import <otherstuff> #import <yetmorestuff> #import "file.h" #import <oh shit is this in the right place?.h> #import <i think this is ok> #define SOME_HACK #import <this better come after that define up there.h> @implementation foo -(void)something:(BOOL)what butthen:(CGRect)thisthing { alert = [[UIAlertView alloc] initWithTitle:@"Hello" message:@"I'm ObjC" delegate:nil cancelButtonTitle:@"I know!" otherButtonTitles:nil]; [alert show]; } Fuck that. 1. Don't Repeat Yourself. Computer have more memory than 1986. 2. Don't forget to turn on warnings-as-errors, otherwise that code above will compile and then break because (of course you noticed) the method declaration doesn't actually match the declaration but the compiler doesn't care because its a brutal hack.

EzGraphs 14y ago

Definitely agree. The place where ruby syntax might shine a bit is in code that does not interact with the Cocoa/IOs specific libraries (e.g. doing calculation, parsing/manipulating strings).