[TheSoftwareGuy]

It irks you because storing source code directly in the final binary is bonkers, but unfortuantely it is the only way to reveal all the complexity that can be exposed in a C header file.

This isn't really just a C problem though. Even rust has a similar problem for propagating macros. The reason for this limitation is really that making an ABI for metaprograms (macros) is exceedingly difficult

[colechristensen]

Are there other languages that provide interfaces as cleanly as exposing C header files?

[java-man]

java interfaces.

I think the concept of coding to an interface (or an API specification) goes beyond what java did. In my professional life, I see people constantly downplaying and ignoring importance of a formal and stable API specification, just to suffer consequences later.

[colechristensen]

If you just give me a .jar do I get those interfaces in a consumable form?

Said differently, can I download your .jar and write my own code to interface with it while on a desert island without any other resources?

[Mister_Snuggles]

Yes.

If you have a random JAR file, an IDE can introspect it to see what classes are in it and what methods are in those classes.

The only exception is if you run it through some kind of obfuscator first.

[Asooka]

Yes but JAR files are basically equivalent to source code parsed and serialised as bytecode with only the most rudimentary optimisations applied. I don't really see a difference between that and carrying gzipped headers with the kernel. Yes, the .class format is cleaner, but it's still very close to what the programmer wrote. Another plus to carrying the header with the kernel is that you can carry the preprocessed header to make sure the user doesn't set the wrong defines, and you can add compiler checks to check that the user isn't using a too old or too new compiler with incompatible ABI.

[java-man]

I suppose the real difference is that with java platform, you get

1. 1/10 or 1/100 compile time

2. full introspection in regards to the interfaces (the topic of this discussion). the implementation classes could be obfuscated, but the point of an interface (and an API in general) that it is not.

3. one could possibly allow multiple versions of the interface be present on the same machine at the same time. for example, when SomeInterfaceV1 is replaced (or extended) by SomeInterfaceV2, it might be possible to provide an adapter that publishes the older interface for backward compatibility.

these are just random thoughts, because the difference between current systems written in c/c++ and a new architecture that uses interface-based approach is too great, I don't think I can name a real system that uses it in practice.

done the API versioning myself several times with complex applications though.