A question about modules

[Myron Alexander]

Lutger wrote:
> Myron Alexander wrote:
>> I am aware of the .di files (although I did not see that dmd can 
>> generate them for you so thanks for the info) but what I want to do is 
>> eliminate the need for a separate .lib and .di files. The way Java 
>> works  is that you do not have to include a textual header with the 
>> .class files, the .class files act as the header and obj in one file.
> 
> Perhaps this is a stupid question, but what is the benefit of this? 
> Templates are handled ok with .lib and .di files. If the problem is ease 
> of use of packaging, then this is taken care of by tools like dsss.

The problem is having to manage separate header and obj files. This was 
always a pain in C and it is a pain in D, less of a pain but one none 
the less (especially with bug 1133). The other problem with .di files is 
that the template code is in plain sight - not so good for closed source 
/ commercial libraries.

Imagine this scenario with the binary modules:

Starting with sources, you compile the library and generate a .dar file 
(D archive).

The .dar file is very much like an uber jar file (with all the meta-data 
issues sorted out).  The .dar file is an archive that contains .dm files 
or D module files.

The D module file acts like the .di file when sources are compiled 
against it, and it acts like the .obj file in the link phase. Although 
it acts like the .di, it is not source, it is some syntax tree or 
optimized representation so it actually speeds up compilation time. The 
.dm file contains templates and other compile time goodies but without 
showing them in plain text. Because of how it works, with the right 
tools, you could convert the .di portion back into readable code, ala 
java jad, but it would not be as readable as the .di, just like jad.

This is not an attempt to lock away the interface code, just not make it 
so obvious. The main benefit to .dar files is that you have a one file 
library that you drop into a directory and compile/link against 
simplifying distribution. Unlike jar files, these are not class loaded 
modules, they are linked into the binary just like .libs.

I hope I made sense, my brain is shutting down and I am having some 
difficulty concentrating.

If you have worked with jar files you will understand the convenience of 
not having to maintain separate include directories and a lib dir.

Best Regards,

Myron.