On Saturday, 28 April 2012 at 23:50:22 UTC, foobar wrote:
On Saturday, 28 April 2012 at 21:02:25 UTC, H. S. Teoh wrote:
* di files - a library should encapsulate all the info
required
to use it. Java Jars, .Net assemblies and even old school;
Pascal
units all solved this long ago.
I agree with the general notion here. Whatever the actual
implementation details are, the API should be strongly tied to
the binary in order to insure consistency and ease of use. I
shouldn't need to worry if the header files match the binary
library. Regarding the human readable API - that's why we have
documentation for.
Mmm well the main reason I see using .di files, is cases when
the input library/file/dll doesn't give you much or any
information. like... most dll's today. There's also tools to
strip that extra debugging and structure information from your
output file, so if you distribute a binary only, you still need
to include it's .h file or .di file.
Cases where this would be far more relevant could be in systems
that don't have a lot of room (mini-distros or recovery disks for
example). I've seen a recovery disk distro with everything you
needed 2 floppies disks. Only reason I don't use floppies anymore
is the ones being made are crap and don't keep data where as 14
years ago I could accidentally put mine through the wash and
still access it's contents. (Cheap bastards)
