On Mon, 28 Nov 2011 18:41:30 +0200, Alexey Veselovsky <alexey.veselovsky@gmail.com> 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).

I agree for C/C++ and even for D, but D's module capabilities make auto-generation of the same thing possible,
which is a very good thing. Now we need to make it work :)

Do you think it'd be a good thing to put the .di file in the generated compiled lib?

That'd be somewhat similar to the c# example.

dmd myprog.d something.dll

searches something.dll for a .di reference, and adds it to the compile command line if it's there.

On 11/28/2011 09:01 AM, so wrote:
> On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
>>> "D has a true module system that supports separate compilation and
>>> generates and uses module summaries (highbrowspeak for "header files")
>>> automatically from source, so you don't need to worry about
>>> maintaining redundant files separately, unless you really wish to, in
>>> which case you can. Yep, that stops that nag right in mid-sentence."
>>>
>>> But it is not true...
>>
>> How is it not true?
>
> I don't know if .di generation from .d or .h is any good or bad,
> but the comparison of auto-generated .di files to hand crafted .h files
> doesn't make sense.

Nobody stops you from hand crafting *.di files.

On Mon, 28 Nov 2011 19:26:23 +0200, Timon Gehr <timon.gehr@gmx.ch> wrote:

> Nobody stops you from hand crafting *.di files.

My point exactly.

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.

2011/11/28 Timon Gehr <timon.gehr@gmx.ch>:
> On 11/28/2011 09:01 AM, so wrote:
>>
>> On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright <newshound2@digitalmars.com> wrote:
>>
>>> On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
>>>>
>>>> "D has a true module system that supports separate compilation and generates and uses module summaries (highbrowspeak for "header files") automatically from source, so you don't need to worry about maintaining redundant files separately, unless you really wish to, in which case you can. Yep, that stops that nag right in mid-sentence."
>>>>
>>>> But it is not true...
>>>
>>> How is it not true?
>>
>> I don't know if .di generation from .d or .h is any good or bad,
>> but the comparison of auto-generated .di files to hand crafted .h files
>> doesn't make sense.
>
> Nobody stops you from hand crafting *.di files.
>

And what sense is in hand crafting .di files? What would you do different? Remove method definitions/private members?

On 11/28/2011 05:07 PM, Maxim Fomin wrote:
> 2011/11/28 Max Samukha<maxter@spambox.com>:
>> On 11/28/2011 02:29 PM, so wrote:
>>>
>>> On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha<maxter@spambox.com>
>>> wrote:
>>>
>>>>> How would you write libraries?
>>>>
>>>> The way they do, for example, in C# - interface definitions are stored
>>>> in the library, no need for separate headers.
>>>
>>> Are we talking about the same thing?
>>> Something like
>>> http://msdn.microsoft.com/en-us/library/ms236403(v=vs.80).aspx?
>>>
>>> So it does what auto-generated .di files does, and turns it into an
>>> abomination, it relies on an IDE feature?
>>
>> No, it has nothing to do with the IDE. The article describes a visual tool
>> for viewing meta-data stored in a .NET binary. You don't have to use it.
>>
>> Specially for you, die-hard IDE haters, this is how to use the terminal to
>> create a mono app and library:
>>
>> 1. Library:
>>
>> nano lib.cs
>> ----
>> using System;
>>
>> public class Lib
>> {
>>     public static void hello() { Console.WriteLine("We don't need no header
>> crap"); }
>> }
>> ----
>>
>> Compile that into a library, lib.dll:
>>
>> dmcs lib.cs -target:library
>>
>> 2. Host:
>>
>> nano app.cs
>> ----
>> class App
>> {
>>     public static void Main()
>>     {
>>         Lib.hello();
>>     }
>> }
>>
>> Compile and run the app:
>>
>> dmcs app.cs -reference:lib.dll
>> ./app.exe
>> We don't need no header crap
>>
>
> [skipped]
>
> 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.
>
> 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.
>     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#: as example above. No headers. Private members are not known. Just
> link program upon compiling to already compiled .dll
>     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.
> 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.

This is in no way related to the D module system, which is quite nicely designed. You are describing issues with the tool chain. Those indeed hamper modular compilation, and should be sorted out eventually. You might want to file a bug report.

On 11/28/2011 06:41 PM, Maxim Fomin wrote:
> 2011/11/28 Timon Gehr<timon.gehr@gmx.ch>:
>> On 11/28/2011 09:01 AM, so wrote:
>>>
>>> On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright
>>> <newshound2@digitalmars.com>  wrote:
>>>
>>>> On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
>>>>>
>>>>> "D has a true module system that supports separate compilation and
>>>>> generates and uses module summaries (highbrowspeak for "header files")
>>>>> automatically from source, so you don't need to worry about
>>>>> maintaining redundant files separately, unless you really wish to, in
>>>>> which case you can. Yep, that stops that nag right in mid-sentence."
>>>>>
>>>>> But it is not true...
>>>>
>>>> How is it not true?
>>>
>>> I don't know if .di generation from .d or .h is any good or bad,
>>> but the comparison of auto-generated .di files to hand crafted .h files
>>> doesn't make sense.
>>
>> Nobody stops you from hand crafting *.di files.
>>
>
> And what sense is in hand crafting .di files? What would you do different?
> Remove method definitions/private members?

The main point is that some people want to have separate specification and implementation. If you don't separate the two, they risk being confused. (as is often the case with the D programming language and its reference implementation.)

In such a setting, the .di file can eg. act as a contract between library implementer and library user.

Eg:

// .di, this is the specification

module awesomeLibrary;

/**
 * Documentation comment
 */

int foo(in int x)
/// maybe documentation comment on in contract
in{assert(x<int.max);}
/// maybe documentation comment on out contract
out(result){assert(result>x);}

class Bar {
    int foo(int x)
    in{...}
    out{...}
}



// .d, the implementation

int foo(int x) { // (contract automatically read from .di file)
    return x+1;
}

class Bar{
    int foo(int x){
        return x + y;
    }
    private int y;
}




And that is the kind of stuff that does not work yet.

so Wrote:

> http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/

o.O

overload a lambda?

Alexey Veselovsky Wrote:

> ok. What about:
> 
> struct Foo {
>     int a;
>     int b;
>     // 100 more fields
>     ...
>     void foo();
> }
> 
> Did I must write in implementation all this 100+ fields in implementation?
> 
> In Ada and Modula there is 2 languages: one for implementation and another for specification. (specification language not subset of implementation language). I think it is right.

In Java separation is done with interfaces. I think it is right.