On Wed, 09 May 2012 17:06:24 -0700, Nick Sabalausky
<[email protected]> wrote:
"H. S. Teoh" <[email protected]> wrote in message
news:[email protected]...
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/
