Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: