On Wed, 09 May 2012 15:43:57 -0700, H. S. Teoh <[email protected]>
wrote:
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.
I am 100% for this. It would be very .NET like. In fact I'm curious enough
what it would take to make this work that I could see myself trying. My
guess is that it needs a new linker with the glorious side-effect of
dumping optlink! In that case it would mean upgrading the D backend to
emit COFF (ELF and Mach-O already support custom sections), which I am
fine with trying to do. Then you would add your AST or other intermediate
representations to a custom section in the object file and the linker
could then link it in. D would then need a way to extract said
information. Which would not be terribly hard. Except that you'll have to
train other compilers how to read that IR. Maybe we could train D to read
the LLVM IR?
2. We should be seriously looking into the idea of making CTFE work by
executing already-compiled code, a la Nemerle (but without needing the
extra build step). There may be enough technical hurdles involved to
hold this back for [the still-hypothtical] D3, but it should at least
be a direction we should be seriously considering. (Unless someone can
already come up with a deal-breaking reason now.) Actually, there's
*FAR* more important things than this right now, like a solid
ARM-tablet toolchain, so this should definitely just be an "on hold
for now" feature.
[...]
+1. You do have the problem of what to do in a cross-compiler, though.
T
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
