I, and basically every language designer since the 80s has disagreed with this. It's needless repetition: all of the information contained in the .h file is duplicated in the .m file. If you really want a nice listing of the exported methods, it's easy to generate that from the .m file.
I agree that there is some merit in the repetition argument, but when discussing a language like Objective-C we must consider that any Objective-C programmer is surely using auto completion to the fullest extend due to the extremely verbose nature of Objective-C naming conventions. The point being that the repetition time is negligible
It is incredible how C based compilation models become so widespread, that younger programmers are completely unaware of sane module systems in other languages with ahead of time compilation toolchains.
Why should the on-disk format of a programming language have anything coupled to a specific use-case for browsing that code? If viewing just the definitions of a method is useful (ie, viewing the header file) then your editor should just let you do so. Letting that bleed into the way the files are organized on disk at the cost of DRY seems a terrible design choice as it serves no purpose other than to make up for poor tooling.
In C/C++/Objective-C the .h files are not use solely for declaring the public interface of a class a lot of times this is where one exposes enums, typedefs, defines which are related to the class in question. The obvious argument against this is using static class members, but I would argue that it adds unnecessary verbosity.
Separation of interfaces and implementation is a core component of pre compiled code distribution, .h files + compiled library.
By simply glancing over a header file one can achieve a quick idea of the interface without consulting the documentation. It's self documenting, reading a Java file in the same way is impossible.
Forward declaration in header files and imports in implementation is also a huge benefit in compilation speed and complexity.
The point is that writing and maintaining such files by hand is a tremendous waste of time.
When I last used C#, I remember Visual Studio would extract and display such public overviews directly from compiled .NET assemblies.
Even if no IDE is involved, something could just auto-generate a text file for distribution. It could even be adorned with a .h file extension for faux-retro appearance!
I do agree partially about the repetition issue, but with a language such as Objective-C you'll auto complete every definition the second time which hardly takes a second, especially with fuzzy auto completion. If time saving is the goal the naming convention for methods is a far better candidate for change
There are still use cases for header files which would require additional syntax if headers are to be generated from .m files. Also the use case of forward declaration comes to mind which would totally lost with an implementation only system
You wouldn't need any of this if it were done properly. C# is a good demonstration of the principle and I'm sure Java could support something similar. In the case of C#, forward declarations are unnecessary, and if you want/need to see something like a .h file then one can be generated automatically from the metadata included in the binary.
In fact Objective-C already includes pretty much everything necessary in the binary already, as you can see by using class-dump. Perhaps additional work would be required to support exposing absolutely everything that might be required, but there's no obvious reason why the language couldn't be extended to allow direct use of compiled code, with no need for a .h file.
