Granularity Of Import Directives In Programming Languages

Look at any C/C++ source code in a large project and you'll see a lot of #include directives at the start of each file. Even in more modern languages like Java, C# and Rust, each file starts with a list of import directives.

These directives are a form of boilerplate code that rarely convey anything useful to human readers. For small files, they can occupy a significant fraction of the file. They have to be maintained by developers. They can cause merge conflicts.

On the other hand, they have some practical benefits. Import directives can be used to resolve ambiguities: when the same name occurs in two different scopes, import directives can be used to map the name to the desired definition. Another benefit is that declaring dependencies explicitly can make it easier to view and track dependencies, and prevent undesirable dependencies. Also, explicit dependencies reduce the problem of new definitions for a name changing the meaning of existing code.

Here's a proposal to capture most of the benefits, and greatly reduce the costs:

• Make import directives per-module instead of per-file or per-translation-unit (except in rare cases where a particular file wants to use a name defined in multiple modules). This lets developers observe and constrain dependencies at the module level, which seems to be all we need.
• Support labelled versions of a module's interface and allow import directives to import the names in a given version.
• When importing between modules in the same project, use wildcard imports that import all public identifiers. When importing from an external project, import a particular interface version. When modules are in the same project --- by which I mean they belong to the same version control repository and are built and tested together --- adding new definitions to a module won't cause latent problems for other modules, so there is no need to protect against that via import directives.

Unfortunately, you can't do those things in C/C++ --- at least, not without penalizing compilation time by creating omnibus header files. In new languages with more modern compilation models, you could. I wonder why it hasn't been done.

A Confession Of Sorts

Reading this LWN article about sexual harassment at conferences led me to another story that was even more compelling and instructive. Read it now or the rest of my post will be unintelligible.

I identified strongly with "Dr Glass" and would have behaved almost exactly the same. But I would have been hiding something, which means Dr Glass might have been too, as far as any observer in the story could know, and I think that adds another layer of implications to the story.

The secret is that I would have been attracted to Luminous Girl, and though I would have successfully suppressed it in my behavior, it would have been hard work. A superhuman observer might notice me glancing at her a little more often than necessary; on a bad day I might even have lustful thoughts about her. This would taint my motives for protecting Luminous from the Awkward Guy: as well as being the right thing to do, it would be fun to live out the fantasy of the Heroic Protector Of The Attractive Woman. Thus, Awkward Guy's mistaken assessment of Luminous as Dr Glass' possession would not be completely off the mark.

Does any of that matter if observable behavior is unchanged? In the Christian worldview, it certainly does, since God looks at the heart. But I think even many materialists would think differently if they knew or suspected what was really going on inside Dr-Glass-as-me.

I would have done one thing very differently from Dr-Glass-of-the-story: I love hiking, but there is no way in the world I would go for a hike alone with an attractive teenage girl I barely know. There is a small possibility of disaster: not rape, but if she made advances, I can't be completely sure I would pass that test --- mainly because I have never faced such a test, and I don't want to. Anyway, the solution is simple: bring a third person along.

Attention NZ TV Sports Interviewers

When interviewing athletes after an event, I want to know what they think, not what you think. So, why are you always making statements and inviting the subject to agree with you? Instead, ask open-ended questions.

Bad:

• "It was tough at there for the last twenty minutes, wouldn't you say?"
• "It looked like you were completely calm at the start?"

Good:

• "What was the toughest part of the match?"
• "How did you feel at the start?"

Same goes for any other kind of interview, but sports interviewers irritate me the most.