grumpy (but light) short takes

[cellio]

Attention appliance manufacturers: there are correct and incorrect ways to fail. Correct is to unambiguously modify output upon failure, so the user knows there's a problem. Incorrect is to blithely go along reporting bogus information while your sensors fail, such as an oven reporting the wrong temperature, a radar detector failing to see the bogeys and reporting that all's clear, or a bathroom scale reporting the wrong weight. Maybe the last isn't as important as the others, but it's still annoying. Stop that. I didn't gain 10+ pounds by changing a battery; honest. You could have beeped or flashed at me to say "battery is low", you know. Sheesh.

An SCA officer posted a badly-worded announcement to the kingdom mailing list, prompting the vast quantities of speculation and challenges that she had hoped to avoid. (There had been none previously on this list.) There are better and worse ways to announce that something bad happened but you're not allowed to release any information yet. A good one is to say, e.g., "It is my sad duty to report that an SCA participant died at a fighting practice this weekend. We do not yet have permission from the family to release more details. Stay tuned.". A bad way is to say "something bad happened, please don't spread rumors, you'll be told what you need to know later, the presence of the word 'sad' in the subject line should give you a hint (nudge nudge, wink wink), no we really won't tell you anything, don't worry about it, don't bug us, and don't gossip". That trick never works. (As the moderator of a related mailing list, I now get to decide how much of the resulting traffic should get through.)

I would like for Java to provide one more publicity level than it does: "internal-public" (or, conversely, "api"). Not all public classes are meant to be used by applications; some are public only because they have to be visible to other classes in your code base. I'd like to be able to label which are which. I'm using a customized javadoc tool to produce the subset of documentation we want, but I get no compiler support this way, so I have to rely on home-grown tools and visual inspection to determine whether I have a self-consistent subset tagged for the API. This could have been easier, given perfect foresight. I'd be delighted if it were easier in the future. (I understand that .NET has a similar concept.)

Comments

[jducoeur]

(I understand that .NET has a similar concept.)

More or less. The .NET "internal" keyword basically means that this item is visible within this assembly, which roughly translates to this .dll. The intent is that assembly boundaries more or less correspond to logical library boundaries, so it basically does what you want. (And in fact, I use the keyword mainly for its autodoc effects.)