On Sunday, 29 April 2012 at 00:40:01 UTC, Era Scarecrow wrote:
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)
floppies, are you for real?!
This is only relevant if you travel a decade or so back in time.
The current generation dvd/Blu-ray discs and USB sticks aren't
good enough for you?
