Proposed improvements to the separate compilation model
Dicebot
m.strashun at gmail.com
Tue Mar 5 00:48:06 PST 2013
On Monday, 4 March 2013 at 23:24:02 UTC, Rob T wrote:
>>> One of the main selling points of the module system is to
>>> prevent exactly what you are proposing, so I think there must
>>> be a better solution.
>
>> Please explain. Main points of module system is to avoid
>> header compilation time hell and control access. I don't how
>> this is relevant to the topic.
>
> This is what I read when I first read about D, modules are
> supposed to be a way to get rid of the need for maintaining
> separate source files, which as you stated also has the desired
> side effect of getting rid of separate header files.
>
> here's one source: http://dlang.org/overview.html
>
> The proposal as I read it, moves us more backwards than
> forwards, and it seems there's a better way as I had described.
> If there's to be a solution, it should be a solution that
> retains one source file. If we need a separation, it should be
> automated to prevent manual duplication and maintenance hell.
I can find nothing on the topic of "separation" issue down that
link. In fact I have never met a C/C++ programmer saying fact of
having a separate headers is a problem, it was a loved feature if
anything. Problem was the way it was designed, via pre-processor.
D fixes this by introducing real symbolic imports and that is
good, but completely irrelevant to the topic of separation of
interface and implementation.
>
>> On Monday, 4 March 2013 at 06:06:14 UTC, Rob T wrote:
>>> Manually maintaining a .di file is a bad idea for what should
>>> be obvious reasons
>>
>> No, they are not obvious at all, please explain.
>
> I did not think that I would have to explain the difference
> between manually maintaining two separate source files
> containing manual duplication of code that must be kept in sync
> vs manually maintaining only one source file with no manual
> duplication of code.
There is close to zero code duplication. This proposal suggests
ability to import definitions from own .di file to main module
file. That means only code duplication is method names (full
signatures for overloaded ones). That actually simplifies
maintenance a lot.
More information about the Digitalmars-d
mailing list