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
