On 7/23/11 12:19 AM, Vladimir Panteleev wrote:
> On Sat, 23 Jul 2011 05:52:12 +0300, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> I don't think it's an either-or situation. For a variety of reasons,
>> some organizations want separate control of the "declaration" and
>> "definition" files. Inability to do so is a common criticism leveled
>> against Java and one of the reasons for the proliferation of XML
>> configuration files and dynamic loading in that language.
>
> Now I'm curious, what are those reasons? Can we improve .di generation
> to accommodate everyone, even if we'd need to add attributes or pragmas
> to the language or frontend?
>
> It just seems to me like this path kills two birds with one stone, and
> is less work overall than doing both.

Improving .di generation is great. Large projects may have policies that restrict changing interface files so as to not trigger recompilation without necessity. Such policies are difficult to accommodate with .di files that are generated automatically.

Andrei

On 7/23/11 12:34 AM, Andrej Mitrovic wrote:
> On 7/23/11, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> Currently, in order for a program with separately-implemented methods to
>> work properly, there must be TWO different files for the same class
>
> Can we get a chat log of this discussion to figure out what is trying
> to be solved here?

It was on the phone.

> interface IFoo
> {
>      int foo();
> }
>
> class Foo : IFoo
> {
>      private int x;
>
>      version(one)
>      {
>          int foo() { return x; }
>      }
>      else
>      version(two)
>      {
>          int foo() { return x++; }
>      }
> }
>
> $ dmd -c foo.d -version=one
>
> or:
>
> class Foo : IFoo
> {
>      mixin(import("FooImpl.d"));
> }
>
> $ dmd -c foo.d -J./my/foo/
>
> There are probably other ways to do this within the existing framework.

Imposing one interface for each class hierarchy is an option, but not an attractive one. It's essentially requiring boilerplate.

> My vote goes to Walter and other contributors to work on fixing
> existing bugs so we can have not a perfect but a working language.

There are not many D large projects at the time being, and everybody who worked on one has had problems. Large projects will come, and the language must be prepared. This _is_ important. Of course, it can happen only of a contributor owns this. We'd be hasty to dismiss the issue though.


Thanks,

Andrei

On Sat, 23 Jul 2011 17:21:26 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> There are not many D large projects at the time being, and everybody who worked on one has had problems. Large projects will come, and the language must be prepared. This _is_ important. Of course, it can happen only of a contributor owns this. We'd be hasty to dismiss the issue though.

FORCING people who want to create large D projects to manually maintain .di files seems like a horrible solution for me. One of the reasons I ran from C++ is due to not having to maintain header files any longer. Whatever your reasons are for manually-maintained .di files, let's not consider them a cure-all for all large project problems.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Sat, 23 Jul 2011 17:16:28 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 7/23/11 12:19 AM, Vladimir Panteleev wrote:
>> On Sat, 23 Jul 2011 05:52:12 +0300, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> I don't think it's an either-or situation. For a variety of reasons,
>>> some organizations want separate control of the "declaration" and
>>> "definition" files. Inability to do so is a common criticism leveled
>>> against Java and one of the reasons for the proliferation of XML
>>> configuration files and dynamic loading in that language.
>>
>> Now I'm curious, what are those reasons? Can we improve .di generation
>> to accommodate everyone, even if we'd need to add attributes or pragmas
>> to the language or frontend?
>>
>> It just seems to me like this path kills two birds with one stone, and
>> is less work overall than doing both.
>
> Improving .di generation is great. Large projects may have policies that restrict changing interface files so as to not trigger recompilation without necessity. Such policies are difficult to accommodate with .di files that are generated automatically.

So don't change a generated .di file's mtime if the contents is identical to the existing version on disk.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On 7/23/11 11:26 AM, Vladimir Panteleev wrote:
> On Sat, 23 Jul 2011 17:21:26 +0300, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> There are not many D large projects at the time being, and everybody
>> who worked on one has had problems. Large projects will come, and the
>> language must be prepared. This _is_ important. Of course, it can
>> happen only of a contributor owns this. We'd be hasty to dismiss the
>> issue though.
>
> FORCING people who want to create large D projects to manually maintain
> .di files seems like a horrible solution for me.

Agreed.

> One of the reasons I
> ran from C++ is due to not having to maintain header files any longer.
> Whatever your reasons are for manually-maintained .di files, let's not
> consider them a cure-all for all large project problems.

Probably this is a misunderstanding. I'm giving a realistic option, not adding a constraint.


Andrei

On Sat, 23 Jul 2011 20:43:13 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

>> One of the reasons I
>> ran from C++ is due to not having to maintain header files any longer.
>> Whatever your reasons are for manually-maintained .di files, let's not
>> consider them a cure-all for all large project problems.
>
> Probably this is a misunderstanding. I'm giving a realistic option, not adding a constraint.

OK. It's just that from where I'm standing, to me it looks like you've already decided on a course without seriously considering the benefits of a more general solution, as well as comparing the amount of work necessary for either path. As you've seen, I have some strong personal opinions about manually-maintained .di files. Performing the same change twice many times per day is the kind of repetitive, mind-numbing work that makes you hate the language, the project, your job, and your boss (for not allowing use of a better language/solution). I've done it in C, C++, Delphi, I don't want to do it in D too.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

Isn't the biggest issue of large D projects the problems with
incremental compilation (e.g.
https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental-building-reliable),
optlink, and the toolchain?

I'm not sure how adding another responsibility to the programmer will
help big projects.
Which existing D projects does this proposal actually apply to? E.g.
which ones will benefit from it?

On Sat, 23 Jul 2011 21:53:30 +0300, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> Isn't the biggest issue of large D projects the problems with
> incremental compilation (e.g.
> https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental-building-reliable),
> optlink, and the toolchain?

Yes. This is a difficult problem.

Due to how DMD is designed, incremental compilation is only reliable when compiling one module at a time. Normally, this would require DMD to parse all imports recursively, for every invocation (thus, for every module). .di files should greatly speed up parsing (and thus, assuming that is the major bottleneck, make one-module-at-a-time compilation faster).

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On 7/23/11 1:53 PM, Andrej Mitrovic wrote:
> Isn't the biggest issue of large D projects the problems with
> incremental compilation (e.g.
> https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental-building-reliable),
> optlink, and the toolchain?

The proposed improvement would mark a step forward in the toolchain and generally in the development of large programs. In particular, it would provide a simple means to decouple compilation of modules used together. It's not easy for me to figure how people don't get it's a net step forward from the current situation.

Andrei

On Sat, 23 Jul 2011 23:16:20 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 7/23/11 1:53 PM, Andrej Mitrovic wrote:
>> Isn't the biggest issue of large D projects the problems with
>> incremental compilation (e.g.
>> https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental-building-reliable),
>> optlink, and the toolchain?
>
> The proposed improvement would mark a step forward in the toolchain and generally in the development of large programs. In particular, it would provide a simple means to decouple compilation of modules used together. It's not easy for me to figure how people don't get it's a net step forward from the current situation.

Then you don't understand what I'm ranting about. It is certainly an improvement, but:

1) We don't have an infinity of programmer-hours. I'm saying that the time would likely be better spent at improving .di generation, which should have a much greater overall benefit per required work unit - and for all I can tell, you don't even want to seriously consider this option.
2) Once manually-maintained .di files are usable, they will be used as an excuse to shoo away people working on large projects (people complaining about compilation speed will be told to just manually write .di files for their 100KLoC projects).

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net