A question about modules

[Ary Manzana]

Nice idea!

I also had this idea some weeks ago (but, I never told it)... And, of 
course, the name was also "dar". It would realy be cool. Especially 
since in Descent I could replace all ocurrences of the word "jar" with 
"dar" and voilà! :-P

Myron Alexander escribió:
> 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.