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]]!

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]]!

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]]!

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]]!

=== 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).

[[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]].

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]]!

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.

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.

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.