Compilation strategy

[Rob T]

On Monday, 17 December 2012 at 22:12:01 UTC, Walter Bright wrote:
> On 12/17/2012 1:53 PM, Rob T wrote:
>> I mentioned in a previous post that we should perhaps focus on 
>> making the .di
>> concept more efficient rather than focus on obfuscation.
>
> We're not going to do obfuscation, because as I explained such 
> cannot work, and we shouldn't do a disservice to users by 
> pretending it does. There are many ways that *do* work, such as 
> PIMPL, which work today and should be used by any organization 
> wishing to obfuscate their implementation.

I agree.

>
> I suspect most file transport protocols already compress the 
> data, so compressing it ourselves probably accomplishes 
> nothing. There are also compressed filesystems, so storing 
> files in a compressed manner likely accomplishes little.

Yes however my understanding is that html based file transfers 
are often not compressed despite the protocol specifically 
supporting the feature. The problem is not with the protocol, its 
that some clients and servers simply do not implement the feature 
or are in a misconfigured state. HTML as you know is very widely 
used for transferring files.

Another thing to consider, is for using byte code for 
interpretation, that way D could be used directly in game engines 
in place of LUA or other scripting methods, or even as a 
replacement for Java Script. Of course you know best if this is 
practical for a language like D, but maybe a subset of D is 
practical, I don't know.

> I have toyed with the idea many times, however, of having dmd 
> support zip files. Zip files can contain an arbitrary file 
> hierarchy, with individual files in compressed, encrypted, or 
> plaintext at the selection of the zip builder. An entire 
> project, or library, or collection of source modules can be 
> distributed as a zip file, and could be compiled with nothing 
> more than:
>
>    dmd foo.zip
>
> or:
>
>    dmd myfile ThirdPartyLib.zip
>
> and have it work. The advantage here is simply that everything 
> can be contained in one simple file.
>
> The concept is simple. The files in the zip file simply replace 
> the zip file in the command line. So, if foo.zip contains a.d, 
> b/c.d, and d.obj, then:
>
>    dmd xx foo.zip
>
> is equivalent to:
>
>    unzip foo
>    dmd xx a.d b/c.d d.obj
>
> P.S. I've also wanted to use .zip files as the .lib file format 
> (!), as the various .lib formats have nothing over .zip files.

Wow, I think that's exactly what we could use! It serves multiple 
optional use cases all at once!

Was there a technical reason for you not getting around towards 
implementing, or just a lack of time?

--rt