CTFE and DI: The Crossroads of D

[Adam Wilson]

On Wed, 09 May 2012 17:06:24 -0700, Nick Sabalausky  
<SeeWebsiteToContactMe at semitwist.com> wrote:

> "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).
>

I agree if that were the sole purpose it would be kind of pointless, but  
the idea is really to give us a system whereby the library itself contains  
all the necessary information to code with it. Much like the .NET Assembly  
strategy.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/