Paulo Pinto Wrote:

> Kagamin Wrote:
> 
> > bearophile Wrote:
> > 
> > > And this is positive because?
> > 
> > You say it as if it's negative.
> 
> 
> For me it is negative as what I understood from this discussion is that contrary to what is described in TDPL, D modules are not ready to prime time.
> 
> At least at the level Modula-2(3), Ada, Delphi, .Net, among others, offer modules.

And what .net modules provide you that D modules don't? Putting aside that I don't remember anything like D modules in .net. .Net has namespaces, which I prefer more, yes.

Maxim Fomin Wrote:

> C#: as example above. No headers. Private members are not known.

Maxim Fomin Wrote:

> C#: as example above. No headers. Private members are not known.

Hmm... Really? Though I remember something about "can't access private member" errors. And yes, metadata sells you everything including private classes (except for comments).

> link program upon compiling to already compiled .dll
>    Actually, this is the best modularization support comparing these 4
> languages.

Ability to use shared assembly in .net comes from it's dynamic properties, not modularization. You can actually access non-existent members, these accesses are resolved at runtime and it will just throw MemberNotFoundException if the access actually occurs, but all other code around will work just fine.

>     with function exporting. And what about a class, its methods and
> private members?). Recompile everything when implementation/interface
>     is changed.

With visual studio recompilation is done whenever a referenced assembly changes, no matter what changed: private member or public.

On 11/28/2011 08:40 PM, Walter Bright wrote:
> On 11/28/2011 4:00 AM, Alexey Veselovsky wrote:
>> ok. I just removed from test.di all non public entities.
>>
>> // D import file generated from 'test.d'
>> module test;
>> public
>> {
>> void foo();
>>
>> struct Boo
>> {
>> public
>> {
>> void boo();
>> }
>> }
>> }
>>
>> Now, let's build it:
>> $ dmd test.di test.d main.d
>> test.d: Error: module test from file test.d conflicts with another
>> module test from file test.di
>>
>> di file not specification, but just another version of implementation?
>
> You cannot compile with both the di and d file.
>
>
>> Compiler doesn't know anything about "specification" files. So, he
>> did't check specification&implementation conformance.
>
> Yes, that's correct.

Actually the first part is not correct. The compiler knows about interface files, and prefers those for imports in case the corresponding .d file is not compiled with the same command (what makes sense).

On 11/29/2011 1:46 AM, Peter Alexander wrote:
> Which means you also get a horrible O(n) algorithm for something that should be
> a couple of compares. Why DMD does this is beyond me.

I did it to get it up and running, and haven't revisited that yet.


> Global float arrays can bloat executables as well:
>
> __gshared int[1_000_000] thisGoesInBss; // barely adds anything
> __gshared float[1_000_000] thisGoesInData; // adds 4MB to exec
>
> float arrays are initialised to NaN in D (in C they init to 0.0f), so they can't
> go in the .bss section (unless you explicitly init to 0.0f).

True, but using large statically allocated arrays of any sort is usually a suboptimal solution. It's better to new or malloc them.

On 11/28/2011 9:40 AM, Timon Gehr wrote:
> On 11/28/2011 05:41 PM, Alexey Veselovsky wrote:
>> Separate hand written specification is rulez for human. It is best
>> short module description (with some useful manually written comments).
>> I like it more then autogenerated docs (by doxygen and so on).
>>
>> Autogenerated specifications (headers and so on) are worst and ugly.
>> But in language like java and C# it is last chance if there is no
>> autogenerated docs and sources.
>
> The compiler _should_ enforce consistence between *.d and *.di files
> when compiling the *.d file. It just does not because nobody has
> implemented it. That is possibly because separate hand written
> specification is rarely used in D development. (alternatively, it could
> be the case that hand written specification is used rarely because DMD
> does not check .d and .di for consistence.)
>
> Autogeneration of *.di files does not have to be the normal case (and
> currently it is so buggy that I managed to find a segfault bug in the
> compiler while compiling a mis-generated *.di file!)
>
> Also, auto generation can hardly even work satisfactory in the general
> case, when there are many static if's/version statements or string mixin
> declarations on module scope.

Can we put this on the priority list. It would be nice to be able to define a specification and then be able to verify against it during unit tests, compilation etc.

On 11/28/2011 8:07 AM, Maxim Fomin wrote:
> Probably i am mistaken that this post supports D modules
> (in a way, showing that header files are crap), but ...
>
> In C# no headers are required, because it includes metadata in dynamic library.
> In your example you link code to compiled library without header files.
> However, this is not possible in D. Programmer have to compile his
> code with library code,
> which also should include all private members, which supposed to be hidden.
> In attempt to eliminate "header crap" D breaks modularization.

This is superficially correct, but in practice is not so. I considered a "metadata" solution for D. It turns out, that D is so fast at parsing, that the "metadata" can simply be the source file stripped of comments. Hence, the genesis of the .di file. The .di file IS the metadata. There really is no difference between that an the C# metadata, except that the C# metadata is not in a user-accessible format.

In particular, the C# metadata still has the private members in it. (If it didn't, you couldn't have inline functions, or value types.)

It's too bad there's no way to 'bind' arbitrary data to shared executable library files, but I have considered making it possible for dmd to read .zip files, so you could stuff all the .di files into a .zip, call it a "library", and voila!

It is possible to stuff .di files into linkable .lib or .a files, however. It wouldn't be a big deal to do that.


> Some comparison of C/C++/C#/D writing libraries.
> C: write in separate .c file, declare exported object as opaque
> structure/void*. No need to recompile program,
>      when library implementation changes.  Program does not know
> anything about private members.

That's the PIMPL idiom, and D supports it as well as C/C++ do. D's associative arrays are implemented using PIMPL.


>     Lib files are no longer required on program compilation. Code can
> be separated though many files.
>     Negative: make changes in min 3 files (program, header, library)
> when interface is changed.
> C++ :  one negative difference  comparing with C is that private
> members are known, and you need recompilation, when you change
> something
>     related to them.

C doesn't hide private members because it has no notion of private members. This is therefore not a 'negative' of C++ relative to C.


> C#: as example above. No headers. Private members are not known. Just
> link program upon compiling to already compiled .dll

This is one of the advantages of deferring compilation until runtime.


>     No GC issues across libraries/program.
>     Actually, this is the best modularization support comparing these 4
> languages.
> D: currently difficulties when generating dynamic libraries in linux.

True, but that's not a defect in the language design.

> Also GC issue when calling D code from D
>      (from http://d-programming-  language.org/dll.html). Programmer
> should ship library code with program (Walter Bright showed simple
> example
>      with function exporting. And what about a class, its methods and
> private members?). Recompile everything when implementation/interface
>      is changed. No way to put class code in separate files. Wired
> "interface file" generation which knows implementation better than its
> author.
>
> In conclusion, I find D module support the worst one.

Walter Bright Wrote:
> It's too bad there's no way to 'bind' arbitrary data to shared executable library files

Would using the resource compiler work on Windows? I'm pretty sure dlls
have icon resources just like exes, so having a string resource in there might work too.

(I don't know that much about it though.)

I know even less about the Linux format than I do the Windows one though :-(

On 12/2/2011 5:44 PM, Adam D. Ruppe wrote:
> Walter Bright Wrote:
>> It's too bad there's no way to 'bind' arbitrary data to shared executable
>> library files
>
> Would using the resource compiler work on Windows? I'm pretty sure dlls
> have icon resources just like exes, so having a string resource in there might work too.
>
> (I don't know that much about it though.)
>
> I know even less about the Linux format than I do the Windows one though :-(


It's a good idea, I think that could work, actually.

On 2011-12-03 02:44, Adam D. Ruppe wrote:
> Walter Bright Wrote:
>> It's too bad there's no way to 'bind' arbitrary data to shared executable
>> library files
>
> Would using the resource compiler work on Windows? I'm pretty sure dlls
> have icon resources just like exes, so having a string resource in there might work too.
>
> (I don't know that much about it though.)
>
> I know even less about the Linux format than I do the Windows one though :-(

It's easy on Mac OS X with its concept of bundles. Just a regular directory with an extension and a specific layout that the applications and the tools recognizes.

-- 
/Jacob Carlborg