Blogs:JaroslavTulach:Practical Design:FixModifiers
From APIDesign
| (7 intermediate revisions not shown.) | |||
| Line 3: | Line 3: | ||
I'd like to attract your attention to my findings about the problems that every new [[API]] designer faces with [[Java]] access modifiers. | 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]] to get the proper context. | + | Please read about [[ClarityOfAccessModifiers]] essay to get the proper context. |
| - | What do you think? Has there 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 | + | 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''. | + | 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 internal purposes. Such methods would not be visible in module [[API]]s at all (so it does not matter | + | 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 [[API]]s 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]] [[API]]s would become cleaner, their [[clarity]] would suddenly increase and no [[API]] designer would ever make those stupid and [[AlternativeBehaviour|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. | Thanks for reading my ''open letter'' and thanks for making [[Java]] better. | ||
| + | |||
| + | <comments/> | ||
--[[User:JaroslavTulach|JaroslavTulach]] 22:06, 25 March 2009 (UTC) | --[[User:JaroslavTulach|JaroslavTulach]] 22:06, 25 March 2009 (UTC) | ||
Current revision
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)
Follow
