Swing - Revision history

JaroslavTulach: /* Example of Bad APIDesign */

2016-08-29T15:39:59Z

Example of Bad APIDesign

←Older revision		Revision as of 15:39, 29 August 2016
Line 12:		Line 12:
	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in the case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).		This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in the case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).

-	Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice design [[API]] where [[Do_Not_Expose_More_Than_You_Want\|less is more]]!	+	Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice: design [[API]]s where [[Do_Not_Expose_More_Than_You_Want\|less is more]]!

JaroslavTulach: /* Example of Bad APIDesign */

2016-08-29T15:39:40Z

Example of Bad APIDesign

←Older revision		Revision as of 15:39, 29 August 2016
Line 12:		Line 12:
	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in the case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).		This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in the case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).

-	Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice design [[API]] where [[Do_Not_Expose_More_Than_You_Want][less is more]]!	+	Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice design [[API]] where [[Do_Not_Expose_More_Than_You_Want\|less is more]]!

JaroslavTulach: /* Example of Bad APIDesign */

2016-08-29T15:38:56Z

Example of Bad APIDesign

←Older revision		Revision as of 15:38, 29 August 2016
Line 10:		Line 10:
	This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP\|object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).		This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP\|object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).

-	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).	+	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in the case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).

	Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice design [[API]] where [[Do_Not_Expose_More_Than_You_Want][less is more]]!		Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice design [[API]] where [[Do_Not_Expose_More_Than_You_Want][less is more]]!

JaroslavTulach: /* Example of Bad APIDesign */

2016-08-29T15:38:09Z

Example of Bad APIDesign

←Older revision		Revision as of 15:38, 29 August 2016
Line 8:		Line 8:
	Few readers of [[TheAPIBook]] complained that it is too UI oriented as some of the examples are about [[Swing]]. True, but it is hard to find better examples of bad [[API Design]]. [[Swing]] is designed in a way SmallTalk people think about design and re-use. All methods are virtual, one can override almost each of them. There are duplicated helper methods which can be overwritten as well.		Few readers of [[TheAPIBook]] complained that it is too UI oriented as some of the examples are about [[Swing]]. True, but it is hard to find better examples of bad [[API Design]]. [[Swing]] is designed in a way SmallTalk people think about design and re-use. All methods are virtual, one can override almost each of them. There are duplicated helper methods which can be overwritten as well.

-	This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP][object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).	+	This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP\|object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).

	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).		This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).

	Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice design [[API]] where [[Do_Not_Expose_More_Than_You_Want][less is more]]!		Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice design [[API]] where [[Do_Not_Expose_More_Than_You_Want][less is more]]!

JaroslavTulach: /* Example of Bad APIDesign */

2016-08-29T15:37:52Z

Example of Bad APIDesign

←Older revision		Revision as of 15:37, 29 August 2016
Line 6:		Line 6:
	=== Example of Bad [[APIDesign]] ===		=== Example of Bad [[APIDesign]] ===

-	Few readers of [[TheAPIBook]] complained that it is too UI oriented as some of the examples are about [[Swing]]. True, but it is hard to find better examples of bad [[API Design]]. [[Swing]] is designed in a way SmallTalk people think about design and re-use. All methods are virtual, one can override them. There are duplicated helper methods which can be overwritten as well.	+	Few readers of [[TheAPIBook]] complained that it is too UI oriented as some of the examples are about [[Swing]]. True, but it is hard to find better examples of bad [[API Design]]. [[Swing]] is designed in a way SmallTalk people think about design and re-use. All methods are virtual, one can override almost each of them. There are duplicated helper methods which can be overwritten as well.

	This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP][object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).		This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP][object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).

JaroslavTulach at 15:36, 29 August 2016

2016-08-29T15:36:31Z

←Older revision		Revision as of 15:36, 29 August 2016
Line 1:		Line 1:
-	[[wikipedia::Swing_(Java)\|Swing]] is standard [[GUI]] for [[Java]] (in spite of many seeing the future in [[JavaFX]]; while everyone should be ~~lookign~~ at [[DukeScript]]!). What do you think, is [[Swing]] following the [[MVC]] paradigm or not? Recently [[Swing]] and [[JavaFX]] interoperability has been greatly [[JavaFX\|improved]].	+	[[wikipedia::Swing_(Java)\|Swing]] is standard [[GUI]] for [[Java]] (in spite of many seeing the future in [[JavaFX]]; while everyone should be looking at [[DukeScript]]!). What do you think, is [[Swing]] following the [[MVC]] paradigm or not? Recently [[Swing]] and [[JavaFX]] interoperability has been greatly [[JavaFX\|improved]].

JaroslavTulach: /* Example of Bad APIDesign */

2016-08-26T10:42:56Z

Example of Bad APIDesign

←Older revision		Revision as of 10:42, 26 August 2016
Line 12:		Line 12:
	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).		This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).

-	Maybe the wide openness of the framework is the reason why it has such a bad reputation.	+	Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice design [[API]] where [[Do_Not_Expose_More_Than_You_Want][less is more]]!

JaroslavTulach: /* Example of Bad APIDesign */

2016-08-26T10:41:43Z

Example of Bad APIDesign

←Older revision		Revision as of 10:41, 26 August 2016
Line 10:		Line 10:
	This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP][object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).		This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP][object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).

-	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).	+	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has such attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).

	Maybe the wide openness of the framework is the reason why it has such a bad reputation.		Maybe the wide openness of the framework is the reason why it has such a bad reputation.

JaroslavTulach: /* Example of Bad APIDesign */

2016-08-26T10:41:13Z

Example of Bad APIDesign

←Older revision		Revision as of 10:41, 26 August 2016
Line 10:		Line 10:
	This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP][object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).		This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP][object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).

-	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in case of [[APILessAPI]] where one can literally change anything. Sometimes people do and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).	+	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in case of [[APILessAPI]] where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).

	Maybe the wide openness of the framework is the reason why it has such a bad reputation.		Maybe the wide openness of the framework is the reason why it has such a bad reputation.

JaroslavTulach: /* Example of Bad APIDesign */

2016-08-26T10:40:45Z

Example of Bad APIDesign

←Older revision		Revision as of 10:40, 26 August 2016
Line 10:		Line 10:
	This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP][object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).		This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP][object oriented]] spaghetti code. One needs [[Swing]] sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of [[cluelessness]] (yet I have to admit it is possible to do some trivial stuff in [[clueless]] mode).

-	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything. Sometimes people do and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).	+	This also has implications for the maintainers of the [[Swing]] framework. They have to assume everyone can override anything - almost like in case of [[APILessAPI]] where one can literally change anything. Sometimes people do and then weird code paths get executed. That means a maintainer of [[Swing]] has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the [[Arithmetica]] class). Not every engineer working on [[Swing]] has attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development).

	Maybe the wide openness of the framework is the reason why it has such a bad reputation.		Maybe the wide openness of the framework is the reason why it has such a bad reputation.