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.
Shorter file sizes is a potential use case, and you could even
allow a
distributor of byte code to optionally supply in compressed
form that is
automatically uncompressed when compiling, although as a trade
off that would
add on a small compilation performance hit.
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.
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.
Yes please.
This is successfully used in Java, their Jar files are actually
zip files that can contain: source code, binary files, resources,
documentation, package meta-data, etc. This can store multiple
binaries inside to support multi-arch (as in OSX).
.NET assemblies accomplish similar goals (although I don't know
if they are zip archives internally as well). D can support both
"legacy" C/C++ compatible formats (lib/obj/headers) and this new
dlib format.
