On Tuesday, 12 June 2012 at 12:23:21 UTC, Dmitry Olshansky wrote:
On 12.06.2012 16:09, foobar wrote:
On Tuesday, 12 June 2012 at 11:09:04 UTC, Don Clugston wrote:
On 12/06/12 11:07, timotheecour wrote:
There's a current pull request to improve di file generation
(https://github.com/D-Programming-Language/dmd/pull/945);
I'd like to
suggest further ideas.
As far as I understand, di interface files try to achieve
these
conflicting goals:
1) speed up compilation by avoiding having to reparse large
files over
and over.
2) hide implementation details for proprietary reasons
> 3) still maintain source code in some form to allow inlining
and CTFE
> 4) be human readable
Is that actually true? My recollection is that the original
motivation
was only goal (2), but I was fairly new to D at the time
(2005).
Here's the original post where it was implemented:
http://www.digitalmars.com/d/archives/digitalmars/D/29883.html
and it got partially merged into DMD 0.141 (Dec 4 2005),
first usable
in DMD0.142
Personally I believe that.di files are *totally* the wrong
approach
for goal (1). I don't think goal (1) and (2) have anything in
common
at all with each other, except that C tried to achieve both
of them
using header files. It's an OK solution for (1) in C, it's a
failure
in C++, and a complete failure in D.
IMHO: If we want goal (1), we should try to achieve goal (1),
and stop
pretending its in any way related to goal (2).
I absolutely agree with the above and would also add that goal
(4) is an
anti-feature. In order to get a human readable version of the
API the
programmer should use *documentation*. D claims that one of
its goals is
to make it a breeze to provide documentation by bundling a
standard tool
- DDoc. There's no need to duplicate this just to provide
another format
when DDoc itself supposed to be format agnostic.
Absolutely. DDoc being built-in didn't sound right to me at
first, BUT it allows us to essentially being able to say that
APIs are covered in the DDoc generated files. Not header files
etc.
This is a solved problem since the 80's (E.g. Pascal units).
Right, seeing yet another newbie hit it everyday is a clear
indication of a simple fact: people would like to think & work
in modules rather then seeing guts of old and crappy OBJ file
technology. Linking with C != using C tools everywhere.
Back in the 90's I only moved 100% away from Turbo Pascal into C
land, when I started using Linux at the University and eventually
spent some time doing C++ as well.
It still baffles me, that in 2012 we still need to rely in crappy
C linker tooling, when in the 80's we already had languages with
proper
modules.
Now we have many mainstream languages with proper modules, but
many
of them leave in VM land.
Oberon, Go and Delphi/Free Pascal seem to be the only languages
with native code generation compilers that offer the binary only
modules solution, while many rely on some form of .di files.
