CTFE and DI: The Crossroads of D

[H. S. Teoh]

On Thu, May 10, 2012 at 08:26:45PM +0200, Paulo Pinto wrote:
> Am 10.05.2012 00:34, schrieb Joseph Rushton Wakeling:
> >On 10/05/12 00:25, H. S. Teoh wrote:
> >>Which is what fueled the market for hundreds (if not thousands) of
> >>JS obfuscators.
> >
> >Well, that's kind of my point really. Is it so bad (from a
> >proprietary point of view) to have to distribute .d rather than .di
> >files, if you can obfuscate them?
> 
> Try to find an error on an obfuscated dump.
> 
> Not fun.
[...]

Yeah, like those Javascript errors from deep within the compressed core
of Yahoo UI or jQuery, which are impossible to figure out because
function names, variable names, etc., are all compressed. It's much
worse with deliberately obfuscated source.

But it still wouldn't stop a determined code thief. This is one of many
reasons I prefer OSS. Trying to prevent code "theft" is an exercise in
futility, reduces utility, and only results in debility.

But if the only way for some people to be happy is to obfuscate their
code, well, then they just have to live with the consequences.

Anyway, all of this just backs up my proposal that instead of
obfuscation, we just store the parsed source (or publically-exposed
parts of it) in the object file in some kind of intermediate form (like
ASTs). Don't bother with .di's at all, just generate the ddocs and let
users use that as reference, you just ship the binary shared lib. The
compiler can load the ASTs as necessary whenever it needs function
bodies, etc.. Problem solved.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry