JaroslavTulach at 22:14, 25 March 2009 - 2009-03-25 22:14:12

←Older revision Revision as of 22:14, 25 March 2009
Line 9: Line 9:
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!?
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 [[API]]s at all (so it does not matter those modifiers are ''fuzzy''). Whoever would 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!
+
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)

JaroslavTulach at 22:12, 25 March 2009 - 2009-03-25 22:12:51

←Older revision Revision as of 22:12, 25 March 2009
Line 9: Line 9:
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!?
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 [[API]]s at all (so it does not matter they are ''fuzzy''). Whoever would 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!
+
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 would 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.
--[[User:JaroslavTulach|JaroslavTulach]] 22:06, 25 March 2009 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 22:06, 25 March 2009 (UTC)

JaroslavTulach at 22:11, 25 March 2009 - 2009-03-25 22:11:42

←Older revision Revision as of 22:11, 25 March 2009
Line 9: Line 9:
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!?
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 they are ''fuzzy''). Whoever would 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!
+
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 they are ''fuzzy''). Whoever would 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.
--[[User:JaroslavTulach|JaroslavTulach]] 22:06, 25 March 2009 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 22:06, 25 March 2009 (UTC)

JaroslavTulach at 22:11, 25 March 2009 - 2009-03-25 22:11:09

←Older revision Revision as of 22:11, 25 March 2009
Line 7: Line 7:
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!
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'''. So can't we instead add the '''callable'''/'''callback'''/'''slot''' ones proposed by [[ClarityOfAccessModifiers]] essay!?
+
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 they are ''fuzzy''). Whoever would 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!
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 they are ''fuzzy''). Whoever would 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!

JaroslavTulach at 22:10, 25 March 2009 - 2009-03-25 22:10:19

←Older revision Revision as of 22:10, 25 March 2009
Line 7: Line 7:
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!
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''. So can't we instead add the '''callable'''/'''callback'''/'''slot''' ones proposed by [[ClarityOfAccessModifiers]] essay!?
+
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'''. So 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 they are ''fuzzy''). Whoever would 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!
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 they are ''fuzzy''). Whoever would 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!

JaroslavTulach at 22:09, 25 March 2009 - 2009-03-25 22:09:08

←Older revision Revision as of 22:09, 25 March 2009
Line 5: Line 5:
Please read about [[ClarityOfAccessModifiers]] essay to get the proper context.
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 with surprise when wants to change something in subsequent release. In the name of [[cluelessness]], this needs to be fixed!
+
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''. So can't we instead add the '''callable'''/'''callback'''/'''slot''' ones proposed by [[ClarityOfAccessModifiers]] essay!?
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''. So can't we instead add the '''callable'''/'''callback'''/'''slot''' ones proposed by [[ClarityOfAccessModifiers]] essay!?

JaroslavTulach at 22:07, 25 March 2009 - 2009-03-25 22:07:08

←Older revision Revision as of 22:07, 25 March 2009
Line 5: Line 5:
Please read about [[ClarityOfAccessModifiers]] essay 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 with surprise when wants to change something in subsequent release. In the name of [[cluelessness]], this needs to be fixed!
+
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 with surprise 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''. So can't we instead add the '''callable'''/'''callback'''/'''slot''' ones proposed by [[ClarityOfAccessModifiers]] essay!?
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''. So can't we instead add the '''callable'''/'''callback'''/'''slot''' ones proposed by [[ClarityOfAccessModifiers]] essay!?

JaroslavTulach at 22:06, 25 March 2009 - 2009-03-25 22:06:40

←Older revision Revision as of 22:06, 25 March 2009
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 with surprise when wants to change something in subsequent release. In the name of [[cluelessness]], this needs to be fixed!
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 with surprise when wants to change something in subsequent release. In the name of [[cluelessness]], this needs to be fixed!

JaroslavTulach: New page: 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 [[ClarityOfAccessMo... - 2009-03-25 22:06:10

New page: 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 [[ClarityOfAccessMo...

New page

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]] 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 with surprise 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''. So 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 they are ''fuzzy''). Whoever would 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.

--[[User:JaroslavTulach|JaroslavTulach]] 22:06, 25 March 2009 (UTC)