Proposed improvements to the separate compilation model

[Dicebot]

On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
> On Tuesday, 5 March 2013 at 19:14:08 UTC, Dicebot wrote:
>>
>> Do you consider necessity to duplicate method signature when 
>> overriding in descendant to be a significant code duplication 
>> too? Because I fail to see the difference in this two cases.
>
> I think there is a difference. For example the compiler will 
> complain when there's a typo, as opposed to getting obfuscated 
> linker errors. No matter if there *is* a sane way to prevent 
> duplication of function overrides, then I'll support it over 
> duplication. This is a common concept, you should *allays* want 
> to avoid unnecessary duplications as every line of extra code 
> you add will exponentially increase the amount of effort 
> required to maintain bug free code.

As far as I get spirit of this proposal, compiler should do the 
very same checks and complain on mismatch between interface and 
implementation. Because it knows it is his interface, contrary to 
C. And there is no sane way to avoid it in the same sense as with 
inheritance - if you want to keep sync between entities in two 
places, some duplication is inevitable. And that is acceptable if 
it is minimal and not error-prone (== verified by compiler).

>> I do not object better automatic .di generation, that is good 
>> for sure. But I do object opposing proposed simplification of 
>> going other way around. Why do you call it "regressing" if it 
>> changes nothing in current behavior? It will considerably 
>> improve my usage scenario (start with .di, write .d after) and 
>> won't affect yours (write only .d)
>
> You'll need to explain more what you are trying to accomplish 
> because I sincerely cannot understand what you are arguing for. 
> Why would anyone ever want to start off with a .di interface?

> ...

Ye, probably this is the root cause of disagreement. My use case 
is not closed-source distribution, it is more of design 
philosophy/approach for large projects.

This is somewhat similar to normal interfaces - it helps 
abstraction to have a single place with all information about 
your module someone out there needs to know : public interface, 
definitions and documentation. Not because your implementation 
source is closed in licensing sense, but because that is the very 
point of abstraction to make your implementation a black-box so 
it may change in any possible way.

It sometimes considered a good approach (which I agree with) to 
start writing module from public interface, before you actually 
know anything about your upcoming implementation and your 
thinking is closer to someone who will later use this module. So 
you write down this single file that can be thrown at other 
programmer with words "Here. It is all you need to know about my 
module to use it. Don't even try to learn more". Then, once you 
are satisfied, actual implementation starts.

Can it be generated? Somewhat. But as this is intended for human 
reading, I'll need to verify result anyway with all attention. To 
make sure function definition order is as planned, no extra 
functions are made public by an accident, documentation 
formatting fits and so on. Especially verifying no extra stuff 
leaked there is hell of a work, much more than any definition 
duplication.

And than there is also other way around. Lets pretend you have 
got your public interface design in same .d file and then started 
digging all the real stuff. It is so easy to forget what was 
intended to be known by outside world and tweak definitions here 
and there a bit, leaking implementation details in process. When 
interface is separate, you need a clear conscious effort to 
change anything about it.

Funny thing, there have been link to a cool presentation about 
OOP and ADT somewhere in this newsgroup 
(http://www.infoq.com/presentations/It-Is-Possible-to-Do-OOP-in-Java) 
and author there actually mentions C separation of header and 
translation unit as a good example of OOP, as opposed to Java. 
Ironically but pretty damn seriously.

tl;dr: I see no additional error-prone cases with this feature if 
implemented with proper compiler verification but it helps for 
maintenance and improves learning curve of project source.