Blogs:JaroslavTulach:Practical Design:FixModifiers

From APIDesign

Jump to: navigation, search

Dear all.

I'd like to attract your attention to my findings about the problems that every new API designer faces with Java access modifiers.

Please read about ClarityOfAccessModifiers essay to get the proper context.

What do you think? Has there already been enough mistakes made by all API designers in the world to convince you that Java deserves better access modifiers? No. Not convinced yet? Then hear the stories of those who subclassed JComponent and overwrote its single method. Let the horror begin... or better not. Just trust me, everyone makes mistakes by leaving methods with multiple meanings in API in one version and then stares agape when wants to change something in subsequent release. In the name of cluelessness, this needs to be fixed!

Can it be fixed? Well, it would require addition of new modifier(s) into Java. That is too risky change! On the other hand, may it is not. It turns out that JDK7 is about to add new access modifier module. But that plan does not improve the Java API design situation at all. Can't we instead add the callable/callback/slot ones proposed by ClarityOfAccessModifiers essay!?

That would work beautifully. New Java modules could use the old damn public, protected, etc. for their internal purposes. Such methods would not be visible in module APIs at all (so it does not matter those modifiers are fuzzy). Whoever wished to provide a module API would have to use the new, conceptually sound callable/callback/slot! Java APIs would become cleaner, their clarity would suddenly increase and no API designer would ever make those stupid and so hard to fix mistakes caused by double meaning modifiers. Let's make a Java better place!

Thanks for reading my open letter and thanks for making Java better.

<comments/>

--JaroslavTulach 22:06, 25 March 2009 (UTC)

Personal tools
buy