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.
