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

[tangerinpenguin.livejournal.com]

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.

Assuming that package visibility isn't sufficient, another approach is to define your class as implementing an interface that only contains the API methods, and set things up so that application code is written to the interface rather than the implementation class.

[cellio]

We've got a number of cases where package visibility isn't sufficient but, possibly, package family would be. For example, if we could restrict something to being visible in com.foo.bar and all of its children (like com.foo.bar.x), but not in com.foo.baz, that would probably solve a lot of our problem cases. Ah well -- in a perfect world...

Writing exclusively to interfaces: interesting idea! Thanks; I hadn't thought of that.