CTFE and DI: The Crossroads of D

[Nick Sabalausky]

"H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote in message 
news:mailman.489.1336603453.24740.digitalmars-d at puremagic.com...
> On Wed, May 09, 2012 at 06:17:41PM -0400, Nick Sabalausky wrote:
>> My take, FWIW:
>>
>> 1. DI is only useful for those anachronistic corporations who beleive
>> in code-hiding (and even then, only the ones who release libs), which
>> regardless of everything else, isn't even *realistic* anyway - there's
>> always reverse-engineering, and with the super-popular JS there *IS
>> NO* pre-compiled form, and yet non-OSS companies *still* get by just
>> fine anyway. If you're relying on the increasingly-irrelevent practice
>> of code-hiding (which there is *no such thing* - only obfuscation,
>> which is exactly what compiling does, it only obfuscates the source,
>> it doesn't hide it), then you need to accept that there *are* going to
>> be things you will *never* be able to do, period, like virtual
>> templates (which *are* possible in theory if all the source is
>> available, even if D doesn't currently allow it).
>
> This is why I kept proposing that .di's should have zero implementation.
> ZERO. No function bodies, no template bodies, NOTHING except API
> information. All of the implementation stuff should be compiled into
> some intermediate form and stuck into special sections in the object
> file that the compiler understands. For example, it can be a serialized
> AST of the corresponding source. When you import the module, the
> compiler automatically looks up the corresponding section in the
> precompiled library and gets whatever info it needs (template bodies,
> CTFE function bodies, whatever).
>
> Yes such a thing can be reverse-engineered, but that is no different
> from distributing your binary in the first place (someone determined
> enough to steal your code will be able to reverse-engineer even the most
> sophisticated obfuscations you apply to your code -- if the CPU can run
> the code, it can be reverse-engineered). It really is just a matter of
> deterring the casual shoulder-peekers from peeking at your "precious"
> code. Code in the form of ASTs stored in the compiled library should be
> deterrent enough -- anyone that actually bothers to reverse engineer
> that is determined enough that you will not be able to stop him no
> matter what you do anyway.
>

There's no need for all that.

The whole point here is "Compile to some obfuscated form" right? So just 
make/use a good code obfuscator. Done. Problem solved.

Inventing an AST storage format just to obfuscate some code is unnecesary 
overkill (although maybe it might have some other use). This "just use an 
obfuscator" approach even makes the whole DI system become totally redundant 
(except for binding to C code, of course).