On 12/16/2012 4:48 PM, H. S. Teoh wrote:
I've proposed this before: when compiling a library, the compiler should process everything into an intermediate form (perhaps even the IR that's used internally to integrate with the codegen), then save that as a sort of partially-compiled object format. This can either be in the form of an object file, or perhaps a custom D-specific format. Everything, including templates, function bodies, etc., is included. Then when you import something from the library, the compiler simply loads the IR from the intermediate format and use that info to compile the code.
This offers nothing over a .di file.
This eliminates the wasted time relexing and reparsing imported files every single time they're used,
Frankly, it's not much faster than parsing the .di file.
and also suitably "hides" the implementation details of the library in a format that isn't easily read. (I mean, let's face it, if someone is desperate enough, he can reverse engineer *anything*, so imagining that shipping a binary is somehow "safer" than shipping a straightforward IR is nonsense. But in the reasonable case, the library being in IR should be disincentive enough for people to not try to break encapsulation.)
It doesn't hide the source in any effective way. There are enough Java byte code => source translators around to prove that. It only takes one such tool to exist (and it's especially easy to create such a tool given D being open source).
An effective way to hide your implementation is to use PIMPL, which D supports well.
This intermediate format can be in the form of some kind of hash table that the compiler can quickly look up referenced symbols from, so there will be almost no overhead.
I've done such (precompiled headers for C++), I've done .di files, and I've done Java bytecode. .di files are superior in nearly every way.
