On 12/17/2012 12:51 PM, deadalnix wrote:
On Monday, 17 December 2012 at 09:40:22 UTC, Walter Bright wrote:
On 12/17/2012 12:54 AM, deadalnix wrote:
More seriously, I understand that in some cases, di are interesting. Mostly if
you want to provide a closed source library to be used by 3rd party devs.
You're missing another major use - encapsulation and isolation, reducing the
dependencies between parts of your system.
For such a case, bytecode is a superior solution as it would allow CTFE.
There is no substantive difference between bytecode and source code, as I've
been trying to explain. It is not superior in any way, (other than being
shorter, and hence less costly to transmit over the internet).
I've also done precompiled headers for C and C++, which are more or less a
binary module importation format.
So, I have extensive personal experience with:
1. bytecode modules
2. binary symbolic modules
3. modules as source code
I picked (3) for D, based on real experience with other methods of doing it. (3)
really is the best solution.
I've often thought Java bytecode was a complete joke. It doesn't deliver any of
its promises. You could tokenize Java source code, run the result through an lzw
compressor, and get the equivalent functionality in every way.
And yes, you can do the same with D modules. Tokenize, run through an lzw
compressor, and voila! a "binary" module import format that is small, loads
fast, and "obfuscated", for whatever little that is worth.
