Proposed improvements to the separate compilation model

[Rob T]

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.

>
> 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?

>
> "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_.

Again this goes back to previous question: Why would you ever 
want to maintain a separation of interface from source? I am 
fully aware of the need to generate a separation for a variety of 
reasons (source code hiding being a significant reason for one) 
but I fail to see any reason why the process ever has to be a 
manual effort. Perhaps you can give me an example?

> 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.

Perhaps then, what I think is the most significant point of all 
is being missed. I can see a very clear reason why in terms of 
source code, the interface and implementation must not be be 
separated. Automated .di generation is a means to solve the need 
for separation when distributing libraries, whoever what goes in 
the .di should not be considered as your "source code" because it 
should be auto generated from the source (eg your .o files are 
not source code in the same way). I

f there's ever a real reason to manually maintain a .di, then 
it's the same as having to hex edit a .o file to make it work, 
ie. the compiler is busted!

--rt