Proposed improvements to the separate compilation model

[Dicebot]

On Tuesday, 5 March 2013 at 17:22:52 UTC, Rob T wrote:
> Clearly there's a misunderstanding going on somewhere. For 
> example when I say "code duplication" you say "There is close 
> to zero code duplication." but from my POV there clearly is 
> code duplication and it is indeed significant and completely 
> unnecessary. Also my understanding of what a module 
> accomplishes is a super set of what you think a module 
> accomplishes, i.e., I include that it solves the code 
> duplication problem, you don't.

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 agree that the current method of automated .di generation is 
> a failure, but I think it is a failure only because the 
> programmer has no control over specifying what goes into the 
> .di file from within the module source, and that the automated 
> .di generation and maintenance implementation is incomplete.
>
> At this point in the discussion, I don't see a sound reason why 
> the automated .di generation cannot be fixed (proposed 
> solutions haven't even been discussed in any depth), and 
> regressing back to manual separation of code seems like a 
> "quick fix" hack that introduces a set of serious problems that 
> cancel out the benefits and probably make the situation worse.

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 seem to support the idea of using manual .di generation and 
> maintenance, which implies to me that you think automated .di 
> generation cannot succeed, is this correct? If so, then I have 
> to ask why?

"Success" is not the right term here, automated generation helps 
different development model - when you just go and write stuff 
you want, compile it and provide something to import to use it. 
Manual .di writing is all about strict separation of interface 
and implementation, not only logical separation, but a physical 
one. I find it a very solid thinking model - removing possibility 
to see an implementation details even by an accident and removing 
the temptation to alter interface few extra times by keeping it 
far from current context. Automatic generation won't help it 
because I _do want to maintain them as separate entities_.

Also all maintenance issues mentioned in this thread for C have 
roots in header being processed in scope of importer translation 
unit, not actually the fact that it is separate. For example, 
naming clash at linking stage is not possible as all names are 
implicitly in modules namespace.