On Tuesday, 5 March 2013 at 00:17:03 UTC, Andrej Mitrovic wrote:
> On 3/5/13, Rob T <alanb@ucora.com> wrote:
>> The relatively primitive IDE that I use allows me to at least
>> perform function folding, which in some ways helps solve the
>> problem, albeit in a poor way, but it hints that better tools can
>> solve the problem rather nicely without a duplication of code.
>
> Code folding is available in almost every text editor, the problem
> (for me) is the indenting.

In that case it would be nice to avoid most of the class name duplication, that's one of the things I really disliked about C++.

class C
{
    void foo1();

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

}

// This avoids all but one duplication of the parent class name.

class.C.inner
{

   void foo()
   {
     // 1 indent
   }

   void foo2()
   {
      // 1 indent
   }

}


--rt

 3/5/13, Rob T <alanb@ucora.com> wrote:
> In that case it would be nice to avoid most of the class name duplication, that's one of the things I really disliked about C++.

I guess you meant:

class A
{
    class B;
}

class A.B
{
    // implementation
}

Ideally both styles would be supported.

Manu:

> +1_000_000_000
>
> Yes please!
> It's near impossible to get a brief overview of a class at a glance in D!

-1 from me. It's one more step toward turning D code into a syntax soup.

Bye,
bearophile

On Monday, 4 March 2013 at 23:24:02 UTC, Rob T wrote:
>>> One of the main selling points of the module system is to prevent exactly what you are proposing, so I think there must be a better solution.
>
>> Please explain. Main points of module system is to avoid header compilation time hell and control access. I don't how this is relevant to the topic.
>
> This is what I read when I first read about D, modules are supposed to be a way to get rid of the need for maintaining separate source files, which as you stated also has the desired side effect of getting rid of separate header files.
>
> here's one source: http://dlang.org/overview.html
>
> The proposal as I read it, moves us more backwards than forwards, and it seems there's a better way as I had described. If there's to be a solution, it should be a solution that retains one source file. If we need a separation, it should be automated to prevent manual duplication and maintenance hell.

I can find nothing on the topic of "separation" issue down that link. In fact I have never met a C/C++ programmer saying fact of having a separate headers is a problem, it was a loved feature if anything. Problem was the way it was designed, via pre-processor. D fixes this by introducing real symbolic imports and that is good, but completely irrelevant to the topic of separation of interface and implementation.

>
>> On Monday, 4 March 2013 at 06:06:14 UTC, Rob T wrote:
>>> Manually maintaining a .di file is a bad idea for what should be obvious reasons
>>
>> No, they are not obvious at all, please explain.
>
> I did not think that I would have to explain the difference between manually maintaining two separate source files containing manual duplication of code that must be kept in sync vs manually maintaining only one source file with no manual duplication of code.

There is close to zero code duplication. This proposal suggests ability to import definitions from own .di file to main module file. That means only code duplication is method names (full signatures for overloaded ones). That actually simplifies maintenance a lot.

On Monday, 4 March 2013 at 23:36:18 UTC, Rob T wrote:
> On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
>> +1_000_000_000
>>
>> Yes please!
>> It's near impossible to get a brief overview of a class at a glance in D!
>>
>>
>
> I agree it's very handy to get an overview of a class or struct or module interface, however I think that the IDE should deal with this problem rather than using a duplication of source code as a solution.

Good presentation is not something IDE can decide for you. For example, you generally want to leave unit tests out of overview, but than still put some of them as extended documentation examples there. That is not something a program can decide for you.

On 2013-03-05 09:48, Dicebot wrote:

> I can find nothing on the topic of "separation" issue down that link. In
> fact I have never met a C/C++ programmer saying fact of having a
> separate headers is a problem, it was a loved feature if anything.
> Problem was the way it was designed, via pre-processor. D fixes this by
> introducing real symbolic imports and that is good, but completely
> irrelevant to the topic of separation of interface and implementation.

We are all here :)

-- 
/Jacob Carlborg

On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
> +1_000_000_000
>
> Yes please!
> It's near impossible to get a brief overview of a class at a glance in D!

Exactly for this reason, what about make this way at least the recommended way, if not the single one?

What is to lose? As about what to win, basically each .d file will carry its .di file (class definition) inside it, and the latter can be easily extracted (both visually and automatically).

Just one note: please allow that the private variables of a class (those that are not exposed outside the file) be declarable outside the main definition of the class, that is with the . syntax. This will completely make declaration and implementation independent, to the point that the class definition is an interface and nothing else.

On 2013-03-05 13:01, eles wrote:

> Exactly for this reason, what about make this way at least the
> recommended way, if not the single one?

You want to break every single piece of D code that uses classes?

> What is to lose? As about what to win, basically each .d file will carry
> its .di file (class definition) inside it, and the latter can be easily
> extracted (both visually and automatically).
>
> Just one note: please allow that the private variables of a class (those
> that are not exposed outside the file) be declarable outside the main
> definition of the class, that is with the . syntax. This will completely
> make declaration and implementation independent, to the point that the
> class definition is an interface and nothing else.

The compiler will need to know the size of the class, for that it needs to know the instance variables.

-- 
/Jacob Carlborg

On Tuesday, 5 March 2013 at 10:41:36 UTC, Jacob Carlborg wrote:
> On 2013-03-05 09:48, Dicebot wrote:
>
>> I can find nothing on the topic of "separation" issue down that link. In
>> fact I have never met a C/C++ programmer saying fact of having a
>> separate headers is a problem, it was a loved feature if anything.
>> Problem was the way it was designed, via pre-processor. D fixes this by
>> introducing real symbolic imports and that is good, but completely
>> irrelevant to the topic of separation of interface and implementation.
>
> We are all here :)

Well, that is why I am so surprised and asking for rationale with better explanation than "it is obvious". I am rather astonished by an overall negative reaction to a long awaited (by me) Andrei proposal.

On Tuesday, 5 March 2013 at 12:19:17 UTC, Jacob Carlborg wrote:
> The compiler will need to know the size of the class, for that it needs to know the instance variables.

Quite an interesting problem to address, by the way. I am on the side that it can be better addressed by providing some general means to duck-typing verification of interfaces for structs and thus eliminating the need to keep anything with private stuff in definitions in .di at all.