@Jim Getzen: Who wants to fool around with header files and pointers and verbosity?
Headers files are just a list of methods and instance variables, which are as useful to the human as the compiler. They might be a bit superfluous in very small projects, but I think anything with more than one window sees benefits.
As for pointers, you don't have to think about them much in Objective 2.0 if you don't want to. At least not if you're building the type of things you'd do in Ruby. In fact, if there was no asterisk you might not even know they exist. If you call into C you'll have think about that, of course.
As for verbosity, that's really determined by Cocoa, not Objective-C. The Ruby bridge doesn't change the method names in the frameworks. All that said, use whatever works best for you. I do wonder, though, how many people are typing all of their Objective-C code by hand, rather than using TextMate or Xcode's code-generation features? I can't imagine doing it all manually.
@Chris: Closures (blocks), symbols, the infinitely superior switch (case) statement are some of my favorites
I really like blocks, and I think they'd be a good addition to Objective-C. I also like auto-return of the last statement, but that might have some unintended side effects.
Unification of interface and implementation
I don't think that's universally a good idea. Headers files are often the only saving grace in large projects or those you don't have the source for. I guess I don't get why anybody would be scared of header files. It's just a list of the class contents.
by Scott Stevenson — Feb 20
Headers files are just a list of methods and instance variables, which are as useful to the human as the compiler. They might be a bit superfluous in very small projects, but I think anything with more than one window sees benefits.
As for pointers, you don't have to think about them much in Objective 2.0 if you don't want to. At least not if you're building the type of things you'd do in Ruby. In fact, if there was no asterisk you might not even know they exist. If you call into C you'll have think about that, of course.
As for verbosity, that's really determined by Cocoa, not Objective-C. The Ruby bridge doesn't change the method names in the frameworks. All that said, use whatever works best for you. I do wonder, though, how many people are typing all of their Objective-C code by hand, rather than using TextMate or Xcode's code-generation features? I can't imagine doing it all manually.
@Chris: Closures (blocks), symbols, the infinitely superior switch (case) statement are some of my favorites
I really like blocks, and I think they'd be a good addition to Objective-C. I also like auto-return of the last statement, but that might have some unintended side effects.
Unification of interface and implementation
I don't think that's universally a good idea. Headers files are often the only saving grace in large projects or those you don't have the source for. I guess I don't get why anybody would be scared of header files. It's just a list of the class contents.