5 ms·

So, you type out the same obj-c code, but with different syntax. Doesnt seem to save any time at all.

by holyjaw 15y ago

kennywinker 15y ago
Well any way you slice it you're still going to have to interface with the Cocoa frameworks that make up the OS. Anything that masks the interface too much just causes friction. e.g. you can't look stuff up in the docs anymore. MacRuby does a bit better job at first glance than this does, but you can't get past the way the framework you're using works. In Objective-C: Person *person = [Person new]; [person name]; [person setName:name]; [person setFirstName:first lastName:last]; and in MacRuby person = Person.new person.name person.setName(name) person.setFirstName(first, lastName:last) As far as I can tell in MobiRuby that'd look something like this: person = Person._alloc._init person._name person._setName _S(name) person._setFirstName _S(first), :lastName, _S(last)
- masuidrive 15y ago
  current method role is tentative. I'll do more improvement.
  - asparagui 15y ago
    ignore the internet, masui, and do whatever you think is best >:3
  - grey-area 15y ago
    In your example you have: alert = UIAlertView._alloc \ ._initWithTitle _S("Hello"), :message, _S("I'm MobiRuby"), :delegate, nil, :cancelButtonTitle, _S("I know!"), :otherButtonTitles, nil alert._show Presumably you don't want to stray from UIKit method names in order to make translation automatic, which is understandable, however translation could be automatic couldn't it - is all that _S necessary? Did you consider a chained, hash syntax something like this: alert = UIAlertView.alloc().initWithTitle(:title => 'Hello', :message => "I'm MobiRuby", :delegate => nil, :cancelButtonTitle => "I know!", :otherButtonTitles => nil).show() With the syntax above someone could omit nil arguments and still get the right result, if you fill in missing arguments for them. Or would that not work for some reason? I understand why you need to keep the method names (for automatic translation), but perhaps the syntax could be a little friendlier and more in line with expectation for Ruby code? I would love to write code for iOS in Ruby (have already written some, but it wouldn't get on the app store due to restrictions), but interfacing with views etc is not too painful in ObjC currently, so if it was more painful in something like this it would put me off. Having looked at your pages further, I see the possibilities of a cross-platform Ruby framework for iOS and Android or WinMo, but if you tie it so tightly to UIKit, how did you plan handling cross-platform issues elegantly? Would that be down to the developers (it is a huge task of course)?
- grey-area 15y ago
  The trouble is, this causes almost as much friction as just using Objective C in the first place. I use Ruby and ObjC extensively (have even mixed them in a desktop app), so I'm familiar with both. While I find ObjC immensely frustrating for dealing with strings and text, and love to use Ruby for that, the syntax above just makes me cringe - it's not idiomatic Ruby, which would be something more like: person = Person.new person.update_attributes(:name => 'Joe', :surname => 'Blogs') OR person = Person.new person.name = "Joe" person.last_name = "Blogs" So why not just use ObjC and call a bundled script which deals well with a specific problem in a rubyish way, and takes input from files, rather than mixing up the two paradigms and ending up with a Frankenstein language which is harder to parse from both sides? I think Apple bans calling bundled scripts on iOS (or did, not sure if the rules have changed), but that's not a technical problem but a political one. I understand people might want to try to use the strengths of Ruby (munging text, some nice libraries), but to get there, you're throwing out some of the nicest things about Ruby - a lovely syntax that doesn't get in your way, and method names you can easily guess. Usually writing Ruby I find I don't have to look up methods and can stay in the flow, but I can't say the same about the cocoa API, with NSString in particular full of huge method names and bizarre syntax for simple operations. So this is throwing out that advantage for the dubious advantage of being able to call cocoa methods from Ruby (using a weird syntax). YMMV
  - jballanc 15y ago
    Assuming that "name", "firstName", and "lastName" are KVC compliant properties, you could do this in MacRuby: person = Person.new person.name = "Joe" person.lastName = "Blogs"

So, you type out the same obj-c code, but with different syntax. Doesnt seem to save any time at all.

by holyjaw 15y ago

So, you type out the same obj-c code, but with different syntax. Doesnt seem to save any time at all.

Well any way you slice it you're still going to have to interface with the Cocoa frameworks that make up the OS. Anything that masks the interface too much just causes friction. e.g. you can't look stuff up in the docs anymore. MacRuby does a bit better job at first glance than this does, but you can't get past the way the framework you're using works. In Objective-C: Person *person = [Person new]; [person name]; [person setName:name]; [person setFirstName:first lastName:last]; and in MacRuby person = Person.new person.name person.setName(name) person.setFirstName(first, lastName:last) As far as I can tell in MobiRuby that'd look something like this: person = Person._alloc._init person._name person._setName _S(name) person._setFirstName _S(first), :lastName, _S(last)

masuidrive 15y ago
current method role is tentative. I'll do more improvement.
- asparagui 15y ago
  ignore the internet, masui, and do whatever you think is best >:3
- grey-area 15y ago
  In your example you have: alert = UIAlertView._alloc \ ._initWithTitle _S("Hello"), :message, _S("I'm MobiRuby"), :delegate, nil, :cancelButtonTitle, _S("I know!"), :otherButtonTitles, nil alert._show Presumably you don't want to stray from UIKit method names in order to make translation automatic, which is understandable, however translation could be automatic couldn't it - is all that _S necessary? Did you consider a chained, hash syntax something like this: alert = UIAlertView.alloc().initWithTitle(:title => 'Hello', :message => "I'm MobiRuby", :delegate => nil, :cancelButtonTitle => "I know!", :otherButtonTitles => nil).show() With the syntax above someone could omit nil arguments and still get the right result, if you fill in missing arguments for them. Or would that not work for some reason? I understand why you need to keep the method names (for automatic translation), but perhaps the syntax could be a little friendlier and more in line with expectation for Ruby code? I would love to write code for iOS in Ruby (have already written some, but it wouldn't get on the app store due to restrictions), but interfacing with views etc is not too painful in ObjC currently, so if it was more painful in something like this it would put me off. Having looked at your pages further, I see the possibilities of a cross-platform Ruby framework for iOS and Android or WinMo, but if you tie it so tightly to UIKit, how did you plan handling cross-platform issues elegantly? Would that be down to the developers (it is a huge task of course)?
grey-area 15y ago
The trouble is, this causes almost as much friction as just using Objective C in the first place. I use Ruby and ObjC extensively (have even mixed them in a desktop app), so I'm familiar with both. While I find ObjC immensely frustrating for dealing with strings and text, and love to use Ruby for that, the syntax above just makes me cringe - it's not idiomatic Ruby, which would be something more like: person = Person.new person.update_attributes(:name => 'Joe', :surname => 'Blogs') OR person = Person.new person.name = "Joe" person.last_name = "Blogs" So why not just use ObjC and call a bundled script which deals well with a specific problem in a rubyish way, and takes input from files, rather than mixing up the two paradigms and ending up with a Frankenstein language which is harder to parse from both sides? I think Apple bans calling bundled scripts on iOS (or did, not sure if the rules have changed), but that's not a technical problem but a political one. I understand people might want to try to use the strengths of Ruby (munging text, some nice libraries), but to get there, you're throwing out some of the nicest things about Ruby - a lovely syntax that doesn't get in your way, and method names you can easily guess. Usually writing Ruby I find I don't have to look up methods and can stay in the flow, but I can't say the same about the cocoa API, with NSString in particular full of huge method names and bizarre syntax for simple operations. So this is throwing out that advantage for the dubious advantage of being able to call cocoa methods from Ruby (using a weird syntax). YMMV
- jballanc 15y ago
  Assuming that "name", "firstName", and "lastName" are KVC compliant properties, you could do this in MacRuby: person = Person.new person.name = "Joe" person.lastName = "Blogs"