On 12/16/11 4:39 PM, Jonathan M Davis wrote:
It wouldn't be. It wouldn't need to be. The programmer is telling the compiler
that there isn't a dependency. It's up to the programmer to make sure that
it's right, and it's wrong, it's their fault. There are plenty of other
features like that in D - just not SafeD.
I don't see progress here over arranging packages and modules to reflect
program structure in a way that clarifies it to the human /and/ the
compiler.
annoying issues in D IMHO.
Adding a language construct that turns off the checking entirely (as you
seem to suggest) is not at all better than having to create a few
additional source files.
I completely disagree. For instance, it's impossible to move the singleton
instances of UTC and LocalTime from std.datetime into another module without
breaking encapsulation, and it's definitely impossible to do it and leave them
as members of their respective classes.
Maybe there's an issue with the design. Maybe Singleton (the most damned
of all patterns) is not the best choice here. Or maybe the use of an
inheritance hierarchy with a grand total of 4 classes. Or maybe the
encapsulation could be rethought.
The general point is, a design lives within a language. Any language is
going to disallow a few designs or make them unsuitable for particular
situation. This is, again, multiplied by the context: it's the standard
library.
Those static constructors clearly
don't rely on any other modules except for the one which gives the declaration
for tzset (and has no static constructors). But if std.file needed a module
constructor, we'd end up with a circular dependency between std.datetime and
std.file when clearly nothing in std.datetime's static constructor relies on
std.file in any way shape or form. It would be a huge improvement to be able to
just mark those static constructors as not relying on any other modules having
their static constructors run first. As it stands, it's a royal pain to deal
with any circular dependencies which pop up and because of that, it quickly
becomes best practice to avoid static constructors as much as possible, which
is a big problem IMHO.
I think this point has gotten into an extreme, a corner of the design
space. Yeah, sky's blue, apple pie is good (and too much of it gives
diabetes), and module dependencies can be messy. But it strikes me as a
bit backwards to add instructions in the core language to lessen
guarantees and make things even messier, when alternatives exist that
foster better dependency control for the very rare situations that need
intervention. It's just not proportional response.
The persona using such a feature would be quite an odd combination - a
developer with sophisticated enough needs to want unchecked dependencies
as a feature, yet naive enough to be unable to solve the problem without
the feature, and yet again sophisticated enough to not make mistakes in
using said feature.
Factoring out the static constructor's contents into a separate module is not
always possible, and it's an ugly solution IMHO. I'd _much_ rather have a
feature where I can tell the compiler that there is no circular dependency so
that it can appropriately order the loading of the modules.
But what's the appropriate order then? :o)
Andrei
