Library standardization

[e-t172]

Hans W. Uhlig a écrit :
> e-t172 wrote:
>> - More efficient. For example, on a Linux distro, if you want to write 
>> a program using a library, you need to install the "dev" package of 
>> the library, which only contains header files. There is no point of 
>> including the implementation in the package, because it is not useful 
>> to the user (and definitely not useful if you only want to compile a 
>> project, not modify it). See the glibc as an example : if you needed 
>> the entire source code of the glibc every time you wanted to compile a 
>> program, this would have been a pure waste in terms of disk space and 
>> compiler efficiency.
> 
> Why should You need extra code files for development. I have always 
> found this annoying, you either need the library or you don't. If the 
> library has API documentation, why would you need headers.

Because API documentation is documentation, not D code that can be 
parsed by a compiler. If I want to use a library, I have to write:

import mylib;

For that to work, you either need the header file "mylib.di" or the D 
file "mylib.d".

>> - Clear separation of "compiled" code and compile-time code. That is, 
>> if a library provides "normal" code (accessed by an API) and 
>> compile-time code (which is compiled in the application that uses the 
>> library, not in the library itself), the two can be clearly 
>> distinguished: "normal" code will only consist of declarations in the 
>> header file, while compile-time code will be entirely defined in the 
>> header file. That way, the user knows what IS in the library (the .a 
>> or .so file), and what will be compiled in his application. (of course 
>> this is already possible, just not as "clearly" for the user)
> 
> Ok, I can see this for fixed constants used by the library. Otherwise, 
> why would you need them.

Huh? Sorry, I don't understand.

>> - Ability to distribute closed-source libraries. I'm against 
>> closed-source libraries, but I know that a lot of people need them.
> 
> Again, I say API Docs!

See my first comment. There is no way API documentation can replace 
header files. Unless, of course, you tell the compiler how to parse and 
understand the API documentation, but that's just awkward.