Hacker News Reader

Comment by K0nserv | Hacker News Reader

Why would we want to get rid of the .h/.m separation? It's a nice feature, Java's single file format is far worse in comparison.

View on HN

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

Stockholm syndrome from too many years in the company of archaic compilation models: it's real and it's scary!

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.

Only worth doing if there are some directives added for public/private directives.

Exposing internals is still bad design.

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.

The separation is nice, but does it need to be done manually?

Couldn't a simple compiler take in .m files and output compiled code + .h files?

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.

True, but that's nothing that couldn't be done in either a separate file or in the .m?

How is it worse?

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

Zapping the entirety of an unnecessarily manual practice is going to be objectively better than providing some typing assistance for it.

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.

There is no .m .h .c .cpp involved. In hypothetical new language we cast off all baggage and stop thinking in archaic C and "C with a twist" terms.

- Turbo Pascal

- Object Pascal

- Delphi

- Modula-2

- Modula-3

- Oberon

- Active Oberon

- Component Pascal

- OCaml

- Haskell

- D

- Ada

- Eiffel

- ...

All languages with native code compiler available, where the header files can bot the manually or automatically generated from the implementation.

Many of them have, or used to have, code browsers and auto complete by reading the metadata stored in the binaries.

C based toolchains are still at stone age, in terms of modular programming support.

That's what javadoc is for. You get a lot more out of browsing through that, than header files.

Reply on news.ycombinator.com