On Sun, 24 Jul 2011 00:54:57 +0300, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
The program prints "424344" as expected.
The problem with this setup is that it's extremely fragile, in ways that
are undetectable during compilation or runtime. For example, just
swapping a and b in the implementation file makes the program print
"08.96566e-31344". Similar issues occur if fields or methods are added
or removed from one file but not the other.
I am not a fun of .di files but there is no reason i can think of that the
compiler should allow such thing. If there is a .di file for the module
compare it to the implementation. If the implementation is different, it
is an error. If it is intended then .di file must be generated explicitly.
So the programmers conclude they need to define an interface for A (and
generally each and every hierarchy or isolated class in the project).
But the same problem occurs for struct, and there's no way to define
interfaces for structs.
I don't understand why people keep bringing this as a solution, this is D.
Ultimately the programmers figure there's no way to keep files separate
without establishing a build mechanism that e.g. generates a.di from
a.d, compares it against the existing a.di, and complains if the two
aren't identical. Upon such a build failure, a senior engineer would
figure out what action to take.
But wait, there's less. The programmers don't have the option of
grouping method implementations in a hierarchy by functionality (which
is common in visitation patterns - even dmd does so). They must define
one class with everything in one place, and there's no way out of that.
My understanding is that the scenarios above are of no value to you, and
if the language would accept them you'd consider that a degradation of
the status quo. Given that the status quo includes a fair amount of
impossible to detect failures and tenuous mechanisms, I disagree. Let me
also play a card I wish I hadn't - I've worked on numerous large
projects and I can tell from direct experience that the inherent
problems are... well, odd. Engineers embarked on such projects need all
the help they could get and would be willing to explore options that
seem ridiculous for projects one fraction the size. Improved .di
generation would be of great help. Enabling other options would be even
better.
Interface design, separate compilation, library development are one of the
many things C++ couldn't make better than C but took it to a new low.
And i don't get why no one else here considers these are big issues and
just go suggest C++ ways, last two times i brought up something related to
this there was only one response. I want to believe it is because me,
failing to express myself :)
