Walter Bright Wrote:

> The only way the linker can detect mismatches is by embedding the hash into the name, i.e. more name mangling.

It's not the only way. You can keep current mangling scheme and store hashes in another place. If the linker doesn't support hashes, everything will just work, if it does, it can provide extra safety for this particular scenario.

Andrei Alexandrescu 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.

Why would javers want to freeze classes instead of interfaces? In C# interfaces can perfectly go to separate files and assemblies.

Kagamin Wrote:

> Walter Bright Wrote:
> 
> > The only way the linker can detect mismatches is by embedding the hash into the name, i.e. more name mangling.
> 
> It's not the only way. You can keep current mangling scheme and store hashes in another place. If the linker doesn't support hashes, everything will just work, if it does, it can provide extra safety for this particular scenario.

Anyways, is it a good idea to force dependency of client on the fields of a class. Fields are implementation details and should not affect client code. This means we end up with plain old interfaces we already have up and working.

On Fri, 22 Jul 2011 18:06:19 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> A chat in IRC revealed a couple of possible improvements to the development scenario in which the interface file (.di) is managed manually and separately from the implementation file (.d).

I have mixed feelings on this proposal.

On one hand, one of the best parts of D over C++ is it's module system.  No more #ifdef __thisfile_included crap, and implementations just sit right where they are defined.  My concern with such an improvement is that it would encourage people (especially C++ coders) to unnecessarily split their implementation from the definition.  I think there have been at least 2 or 3 people ask how to do this in D.  I really like that implementation and definition are all in one file, and cannot be out of sync (a common problem with C++).  Already di files allow for these problems to creep back in, but I understand it's a necessary evil.

On the other hand, the duplication of definitions and functions for inlining when you do want to use .di files is a real problem, and this would seem to address it.  And as you point out, it doesn't eliminate the existing solution.

Plus, D does not suffer from multiple-personality syndrome like C++ can.  For example, including a file more than once with different macro definitions to alter the impact of the include file.

As a criticism though, I don't really like this:

module std.foo;
import std.foo; // huh?

I know we don't want to add too much to the syntax, but can we make that line a bit more descriptive?  and also less redundant?  Suggestion:

module std.foo;
import interface; // imports the .di file that corresponds to std.foo.

I know that's keyword abuse, but it's kind of accurate ;)

-Steve

On 7/25/11 11:19 AM, Steven Schveighoffer wrote:
> On Fri, 22 Jul 2011 18:06:19 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> A chat in IRC revealed a couple of possible improvements to the
>> development scenario in which the interface file (.di) is managed
>> manually and separately from the implementation file (.d).
>
> I have mixed feelings on this proposal.
>
> On one hand, one of the best parts of D over C++ is it's module system.
> No more #ifdef __thisfile_included crap, and implementations just sit
> right where they are defined. My concern with such an improvement is
> that it would encourage people (especially C++ coders) to unnecessarily
> split their implementation from the definition. I think there have been
> at least 2 or 3 people ask how to do this in D. I really like that
> implementation and definition are all in one file, and cannot be out of
> sync (a common problem with C++). Already di files allow for these
> problems to creep back in, but I understand it's a necessary evil.

Once we accept that, we should also acknowledge its big issues and fix them. The current .di model is marred by numerous problems.

Andrei

On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu wrote:
> 1. The compiler shall accept method definitions outside a class.

Sorry to bump this old thread, but after having spent some time with D I like the idea of having the ability to implement class methods outside of the class, but I would like to have this ability in the same file as the module:

module test;

class C
{
    void foo1();

    void bar1()
    {
        // N1 -- two indents
    }

    class Inner
    {
        void foo2();
        void bar2()
        {
            // N2 -- three indents
        }
    }
}

// if allowed:

void C.foo()
{
    // 1 indent
}

void C.Inner.foo2()
{
    // 1 indent
}

The benefit? Avoiding the indentation tax. I've come to find it really annoying that hundreds of lines of code end up being indented twice or more times. Changing the indentation setting is not a real solution, I like my indentation size the way it is, I just don't like being forced to indent too much because of the requirement to implement everything inline.

I really like this and never never understood reason behind automatically generated .di files, as much as difficulties with separation of interface and implementation. If there is one thing that prevents me to say that D module system is 100% better than C++ - here it is. If there is something I would like to write by hand in first place, it is .di file for sure, because it is the one intended to be read by broader programmer count.

Add in my proposals about protection attributes and inner linkage and that would have been module system I really love.

But I tend to agree that importance of this issues is not urgent enough to prioritize it anyhow. Adding "prepproved" enhancement request after convincing D community may be enough for now.

Regarding CTFE - it is a reason to not use this layout for generic algorithm libraries and similar stuff, but there is no point in allowing application module code for CTFE by an accident.

On Sunday, 3 March 2013 at 10:47:34 UTC, Dicebot wrote:
> Regarding CTFE - it is a reason to not use this layout for generic algorithm libraries and similar stuff, but there is no point in allowing application module code for CTFE by an accident.

It is the virtual vs final by default argument. You'll find very good reason to do so, but it has drawback. I'm not sure if one is really better than the other.

On Sunday, 3 March 2013 at 11:03:55 UTC, deadalnix wrote:
> On Sunday, 3 March 2013 at 10:47:34 UTC, Dicebot wrote:
>> Regarding CTFE - it is a reason to not use this layout for generic algorithm libraries and similar stuff, but there is no point in allowing application module code for CTFE by an accident.
>
> It is the virtual vs final by default argument. You'll find very good reason to do so, but it has drawback. I'm not sure if one is really better than the other.

How so? virtual vs final is a lot about overriding by accident (or not overriding), VMT overhead and similar things that do make difference. CTFE is all about either giving access to source for evaluation or not. Where is the catch?

On Sunday, 3 March 2013 at 11:08:33 UTC, Dicebot wrote:
> On Sunday, 3 March 2013 at 11:03:55 UTC, deadalnix wrote:
>> On Sunday, 3 March 2013 at 10:47:34 UTC, Dicebot wrote:
>>> Regarding CTFE - it is a reason to not use this layout for generic algorithm libraries and similar stuff, but there is no point in allowing application module code for CTFE by an accident.
>>
>> It is the virtual vs final by default argument. You'll find very good reason to do so, but it has drawback. I'm not sure if one is really better than the other.
>
> How so? virtual vs final is a lot about overriding by accident (or not overriding), VMT overhead and similar things that do make difference. CTFE is all about either giving access to source for evaluation or not. Where is the catch?

That is the same debate with the same argument.

People that argue for final by default say that you can still make the function virtual afterward if needed, when the people arguing the other way around say that you may not know in advance what will be overloaded, and that you create unnecessary restriction.

CTFEability is exactly the same argument.

Overriding by accident is not a concern as you have to specify override anyway.