On Sunday, 8 September 2013 at 12:53:11 UTC, Dicebot wrote:
>> Seriously, this goes against everything you learn as a programmer, nothing should ever be typed twice and then to say that the declaration and implementation could be different just boggles my mind?!?! Great more work!
>
> It is no different from overriding `interface` methods in class. From the code structure point of view, declaration is interface. Implementation is implementation. Keeping those separate may sometimes/often be useful.
>
> That said, I am strongly against permissive rules proposed in this DIP. It should be similar to overriding rules - any smallest difference between to signatures and program stops compiling. Otherwise it is maintenance hell.

Well you've just argued against your first paragraph there. The issue is (as you recognise) the extra complexity introduced with having a declaration and an implementation both of which could be different and/or not clear how they relate. But it goes further than that. If this DIP is implemented and you are working with code written like this you now have to change the code in two places when you want to update a method. Also you now have to find the implementation or declaration which is a total pain when not using an IDE. You now have more files. Longer compilation times. All for what? Not using -D on the command line? Come on!

This is entirely different to how overloading works because in that scenario you are explicitly saying in your code this method overrides the parent (or interface) with this one that matches that signature exactly. There is no duplication, it's explicit overriding which is different.

Also could you give me any examples of where keeping the declaration separate to the implementation is "sometimes/often useful". Because IMHO it only adds work and Java and C# do just fine.

I don't think Walter realises how much of a plus point it is for D to not have this 'feature'. I mean if this was implemented and code started appearing written in this style (as it will) why would people choose D over C++ to get stuff done when they both offer the same headaches now?

Am 08.09.2013 15:11, schrieb Gary Willoughby:
> On Sunday, 8 September 2013 at 12:53:11 UTC, Dicebot wrote:
>>> Seriously, this goes against everything you learn as a programmer,
>>> nothing should ever be typed twice and then to say that the
>>> declaration and implementation could be different just boggles my
>>> mind?!?! Great more work!
>>
>> It is no different from overriding `interface` methods in class. From
>> the code structure point of view, declaration is interface.
>> Implementation is implementation. Keeping those separate may
>> sometimes/often be useful.
>>
>> That said, I am strongly against permissive rules proposed in this
>> DIP. It should be similar to overriding rules - any smallest
>> difference between to signatures and program stops compiling.
>> Otherwise it is maintenance hell.
>
> Well you've just argued against your first paragraph there. The issue is
> (as you recognise) the extra complexity introduced with having a
> declaration and an implementation both of which could be different
> and/or not clear how they relate. But it goes further than that. If this
> DIP is implemented and you are working with code written like this you
> now have to change the code in two places when you want to update a
> method. Also you now have to find the implementation or declaration
> which is a total pain when not using an IDE. You now have more files.
> Longer compilation times. All for what? Not using -D on the command
> line? Come on!
>
> This is entirely different to how overloading works because in that
> scenario you are explicitly saying in your code this method overrides
> the parent (or interface) with this one that matches that signature
> exactly. There is no duplication, it's explicit overriding which is
> different.
>
> Also could you give me any examples of where keeping the declaration
> separate to the implementation is "sometimes/often useful". Because IMHO
> it only adds work and Java and C# do just fine.
>
> I don't think Walter realises how much of a plus point it is for D to
> not have this 'feature'. I mean if this was implemented and code started
> appearing written in this style (as it will) why would people choose D
> over C++ to get stuff done when they both offer the same headaches now?

Not only Java and C#, but any other language with module support, even the ones that have native compilers by default.

The ones that offer interface definitions, like Delphi, Modula-{2,3}, ML family among many others, have a model that D already offers via the .di files.

So I also agree this is a step backwards.

--
Paulo

On Sunday, 8 September 2013 at 13:11:01 UTC, Gary Willoughby wrote:
>> That said, I am strongly against permissive rules proposed in this DIP. It should be similar to overriding rules - any smallest difference between to signatures and program stops compiling. Otherwise it is maintenance hell.
>
> Well you've just argued against your first paragraph there. The issue is (as you recognise) the extra complexity introduced with having a declaration and an implementation both of which could be different and/or not clear how they relate.

Not really. Issue is cognitive load of matching definition and declaration if they are allowed to be out of sync.

> But it goes further than that. If this DIP is implemented and you are working with code written like this you now have to change the code in two places when you want to update a method. Also you now have to find the implementation or declaration which is a total pain when not using an IDE.

I consider it a minor inconvenience for a certain structural gain.

> This is entirely different to how overloading works because in that scenario you are explicitly saying in your code this method overrides the parent (or interface) with this one that matches that signature exactly. There is no duplication, it's explicit overriding which is different.

overloading != overriding. I am speaking about overriding. From the maintenance point of view this two snippets are identical:
---
interface A
{
    void foo();
}

class A_prim : A
{
    void foo() { }
}
---
class A
{
    void foo();
}

void A.foo()
{
}
---

Same amount of duplication, same amount of information available for compiler verification.

> Also could you give me any examples of where keeping the declaration separate to the implementation is "sometimes/often useful". Because IMHO it only adds work and Java and C# do just fine.

I have never worked on any reasonably large Java/C# code base. But it C++ once amount of entities grows large enough clear interface overview in header files is basically only way to get familiar quickly with sources.

As I have already said it is good for same reasons interfaces are good - easier to abstract away information you shouldn't be aware of when working in large teams.

> I don't think Walter realises how much of a plus point it is for D to not have this 'feature'. I mean if this was implemented and code started appearing written in this style (as it will) why would people choose D over C++ to get stuff done when they both offer the same headaches now?

I don't think it will matter at all. As it was mentioned, usage of such feature tends to be private business of certain project - it won't propagate to yours  if you don't use it.

And you really underestimate issues of C++ that force programmers to seek other languages. Separation of definition and declaration won't probably be even in top 50.

On Sunday, 8 September 2013 at 12:46:49 UTC, Gary Willoughby wrote:
> I'm absolutely against this DIP.
>
> This proposal is just going back to the hell of header files again. Why on earth would you emulate C/C++ when D was supposed to be designed taking into account lessons learned from them. This is unnecessary complexity added for the sake of a few programmers who can't get out of C++ mode. I think you need to have a good hard think about *why* header files were introduced into those early languages and then consider if that reason is still valid. Personally i don't think it is. Java and C# do just fine without this.
>
> Seriously, this goes against everything you learn as a programmer, nothing should ever be typed twice and then to say that the declaration and implementation could be different just boggles my mind?!?! Great more work!
>
> If implemented, i will never used this feature and i will never deal with code that uses it either. I choose D *purely* because it didn't have this header file nonsense. If i find in future i start seeing more and more of this style of D code i would just move on to use something else that doesn't have all this extra baggage and work associated with it. Just because Manu brings it up randomly you decide to create a DIP?
>
> In reality this is a documentation issue. Which has already been addressed by DDOC or *.di files. If data exists in one form, and it is needed in another, that's work a computer should do. Not a human! IDE's also give you numerous tools to get class overviews and such. If you are suggesting that you also need these class overviews in code to be viewed on github etc, just use comments. They are as arbitrary and simpler to implement.
>
> Honestly this DIP is going backwards, i was under the impression D was going forwards! I am so disappointed.

I totally agree (stating this just in case number of votes matters).

> I have never worked on any reasonably large Java/C# code base. But it C++ once amount of entities grows large enough clear interface overview in header files is basically only way to get familiar quickly with sources.

This is a job for the *documentation* and if documentation is automatically generated (which it is, see '-D') then this argument is moot.

> I don't think it will matter at all. As it was mentioned, usage of such feature tends to be private business of certain project - it won't propagate to yours  if you don't use it.

Except when dealing with books, tutorials, third party libraries, pull requests, etc...

I dismay.

On Sunday, 8 September 2013 at 12:34:06 UTC, Andrej Mitrovic wrote:
> On 9/8/13, Michel Fortin <michel.fortin@michelf.ca> wrote:
>> So I'd like to suggest this: allow a .d file to "import" its corresponding
>> .di file.
>
> This is actually what Andrei proposed as well.

+42

On Sunday, 8 September 2013 at 15:09:31 UTC, Gary Willoughby wrote:
> This is a job for the *documentation* and if documentation is automatically generated (which it is, see '-D') then this argument is moot.

Documentation is tool to help with cross-project learning. I have never seen one used internally inside the same project. It simply does not work that way, not even close in convenience to matching source organization. Takes more time, uses different information representation other than plain code, is not applicable in some contexts (i.e. git log).

Built-in IDE tools are generally better for that but, as I have already said, I am not aware of a single one that does it conveniently enough.

> Except when dealing with books, tutorials, third party libraries, pull requests, etc...

That applies to any other possible feature that may or may not exist in D. What I do mean though is that you shouldn't care how third-party library is organized - for you it remains same import statement and documentation investigation that requires to change nothing in your code flow even if third-party library uses this feature and you do not.

On Sunday, 8 September 2013 at 15:14:51 UTC, deadalnix wrote:
> On Sunday, 8 September 2013 at 12:34:06 UTC, Andrej Mitrovic wrote:
>> On 9/8/13, Michel Fortin <michel.fortin@michelf.ca> wrote:
>>> So I'd like to suggest this: allow a .d file to "import" its corresponding
>>> .di file.
>>
>> This is actually what Andrei proposed as well.
>
> +42

That is why I had a feeling I have already seen it somewhere :)

On Sunday, 8 September 2013 at 13:00:11 UTC, Dmitry Olshansky wrote:
> 08-Sep-2013 16:02, Michel Fortin пишет:
[Snip]
>>
>> Example:
>>
>>     // test.di
>>     module test;
>>
>>     class A {
>>         void foo(int a, int b);
>>     }
>>
>>     // test.d
>>     import module test; // import declarations from the .di file
>>
>>     void A.foo(int a, int b) {
>>         // member function definition
>>     }
>>
>
> With this suggestion it finally becomes sane.

+1

On 2013-09-08, 12:46, Tove wrote:

> Wouldn't this style be an acceptable compromise instead? with both declaration and definition 100% identical.
>
> struct S
> {
>    // member function declarations
>    static int mfunc1(int a, int b = 5) pure;
>    static int mfunc2(int a, int b = 5) pure;
>    static int mfunc3(int a, int b = 5) pure;
>
>    // member function definitions
>    static int mfunc1(int a, int b = 5) pure
>    {
>    }
>    static int mfunc2(int a, int b = 5) pure
>    {
>    }
>    static int mfunc3(int a, int b = 5) pure
>    {
>    }
> }

The problem here is the compiler does not enforce that all
definitions are present in the declaration list. Apart from that, I
feel this is the correct solution to the problem.

-- 
  Simen