@nikolaus: The question "who's scared of header files" makes me want to say: Not me! I am not scared of header files. They are just totally unnecessary and get in the way of coding.
The first programming languages I used were scripting languages, so I know exactly what you mean. When I first started with C and Objective-C, I wondered why you'd want a separate file that just lists functions. Eventually, though, I came to the conclusion that header files are so simple that it's not worth worrying about whether they should be there or not.
That said, I do appreciate them when trying to figure out a 16k line class file. Yes, there are documentation files, but often I just want to a see a straight list of functions that the compiler approves of. In any case, the main reason they need to be there is for transparent C compatibility.
I wouldn't mind so much if XCode were an actually good IDE a'la Eclipse or IDEA. Writing a new method would then work like this: 1 - Write it straight into the .m file. It ends up with a warning, one-click quick fix offers to add the definition into the corresponding .h file, done in the blink of an eye. But that's not what XCode does.
There's no reason that feature couldn't be in Xcode, so you should file an enhancement request. I used Eclipse for several months. I agree it has great functional features, but the user experience is far from what I want in a Mac app. What I'd like is for Apple to roll all of the great Eclipse features into the Xcode UI model.
Compared to Ruby there is still lots of code clutter in a typical Objective C class. So I just want to point out why Ruby is superior
I love Ruby. I'm a huge fan. But I don't think it's a better language for Cocoa than Objective-C is. Just as Rails was designed for Ruby, Cocoa was designed for Objective-C. For both frameworks, the entire design philosophy revolves around the language.
pointers * which you can ignore (then why are they there), its a mess.
The pointer symbols are there to satisfy C. I complete agree with you that it would better if we didn't need them, but the transparent integration with C makes it worthwhile. It's hard to overstate just how valuable that is for desktop apps.
by Scott Stevenson — Dec 20
The first programming languages I used were scripting languages, so I know exactly what you mean. When I first started with C and Objective-C, I wondered why you'd want a separate file that just lists functions. Eventually, though, I came to the conclusion that header files are so simple that it's not worth worrying about whether they should be there or not.
That said, I do appreciate them when trying to figure out a 16k line class file. Yes, there are documentation files, but often I just want to a see a straight list of functions that the compiler approves of. In any case, the main reason they need to be there is for transparent C compatibility.
I wouldn't mind so much if XCode were an actually good IDE a'la Eclipse or IDEA. Writing a new method would then work like this: 1 - Write it straight into the .m file. It ends up with a warning, one-click quick fix offers to add the definition into the corresponding .h file, done in the blink of an eye. But that's not what XCode does.
There's no reason that feature couldn't be in Xcode, so you should file an enhancement request. I used Eclipse for several months. I agree it has great functional features, but the user experience is far from what I want in a Mac app. What I'd like is for Apple to roll all of the great Eclipse features into the Xcode UI model.
Compared to Ruby there is still lots of code clutter in a typical Objective C class. So I just want to point out why Ruby is superior
I love Ruby. I'm a huge fan. But I don't think it's a better language for Cocoa than Objective-C is. Just as Rails was designed for Ruby, Cocoa was designed for Objective-C. For both frameworks, the entire design philosophy revolves around the language.
pointers * which you can ignore (then why are they there), its a mess.
The pointer symbols are there to satisfy C. I complete agree with you that it would better if we didn't need them, but the transparent integration with C makes it worthwhile. It's hard to overstate just how valuable that is for desktop apps.