Program size, linking matter, and static this()

[Andrei Alexandrescu]

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