Compilation strategy

[Walter Bright]

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.