| ←Older revision | Revision as of 05:18, 24 August 2025 | ||
| Line 2: | Line 2: | ||
<startFeed /> | <startFeed /> | ||
| + | |||
| + | ==== Angular 2.0 Syndrome ==== | ||
| + | |||
| + | Who remembers [[Angular#Angular_2.0_Syndrome|Angular]] these days anyway? I do. But mostly as a synonym for a ''total failure of maintaining a framework''! | ||
| + | |||
| + | --[[User:JaroslavTulach|JaroslavTulach]] 05:18, 24 August 2025 (UTC) | ||
==== Feeling the Pain! ==== | ==== Feeling the Pain! ==== | ||
| ←Older revision | Revision as of 06:02, 22 December 2021 | ||
| Line 2: | Line 2: | ||
<startFeed /> | <startFeed /> | ||
| + | |||
| + | ==== Feeling the Pain! ==== | ||
| + | |||
| + | It always helps when maintainers of a library or framework feel the pain of using it themselves. Then they become more open to address limitations of their own design. It's not users of (even of some obscure feature of) a library that shall "feel some pain every time they use it, to keep the usage as limited as possible". The maintainers should feel the pain. That helps them to get more [[Pragmatic]] and less academic! | ||
| + | |||
| + | --[[User:JaroslavTulach|JaroslavTulach]] 06:02, 22 December 2021 (UTC) | ||
==== The [[Genetics]] of an [[APIDesign]] ==== | ==== The [[Genetics]] of an [[APIDesign]] ==== | ||
| ←Older revision | Revision as of 09:53, 29 June 2021 | ||
| Line 3: | Line 3: | ||
<startFeed /> | <startFeed /> | ||
| - | ==== The [[Genetics]] of [[APIDesign]] ==== | + | ==== The [[Genetics]] of an [[APIDesign]] ==== |
The [[Genetics]] of an API design comes with own surprises: APIs shall not be copied, but only re-implemented. That's the paradox of copying an API! | The [[Genetics]] of an API design comes with own surprises: APIs shall not be copied, but only re-implemented. That's the paradox of copying an API! | ||
| ←Older revision | Revision as of 06:29, 29 June 2021 | ||
| Line 2: | Line 2: | ||
<startFeed /> | <startFeed /> | ||
| + | |||
| + | ==== The [[Genetics]] of [[APIDesign]] ==== | ||
| + | |||
| + | The [[Genetics]] of an API design comes with own surprises: APIs shall not be copied, but only re-implemented. That's the paradox of copying an API! | ||
| + | |||
| + | --[[User:JaroslavTulach|JaroslavTulach]] 06:29, 29 June 2021 (UTC) | ||
==== The Science of [[APIDesign]] ==== | ==== The Science of [[APIDesign]] ==== | ||
| ←Older revision | Revision as of 06:08, 15 October 2020 | ||
| Line 2: | Line 2: | ||
<startFeed /> | <startFeed /> | ||
| + | |||
| + | ==== The Science of [[APIDesign]] ==== | ||
| + | |||
| + | [[ScienceOfAPIDesign]] is possible and can be almost as sharp as the most accurate science of all times - geometry. To achieve such sharpness it is better/easier/more useful to focus on binary compatibility in Java rather than source compatibility. Enhancing language can mitigate many issues, but regular library designers (mere mortals) can't change their language. We can only learn what advises the [[ScienceOfAPIDesign]] offers and use them in our daily policies. Or don't use them (but preferably knowing why). | ||
| + | |||
| + | Anyone willing to join the quest on making [[ScienceOfAPIDesign]] better and sharper? | ||
| + | |||
| + | --[[User:JaroslavTulach|JaroslavTulach]] 06:08, 15 October 2020 (UTC) | ||
==== Adding [[DefaultMethods]] in a 100% [[BackwardCompatible]] Way! ==== | ==== Adding [[DefaultMethods]] in a 100% [[BackwardCompatible]] Way! ==== | ||
Adding DefaultMethods in a 100% BackwardCompatible Way!
| ←Older revision | Revision as of 06:12, 30 September 2020 | ||
| Line 6: | Line 6: | ||
I took a part in a tweetting about [[BinaryCompatibleDefaultMethods|incompatibilities related to | I took a part in a tweetting about [[BinaryCompatibleDefaultMethods|incompatibilities related to | ||
| - | CharSequence.isEmpty()]] over the weekend and I asked myself a simple question: ''Is it possible to add a default method in a 100% | + | CharSequence.isEmpty()]] over the weekend and I asked myself a simple question: ''Is it possible to add a default method in a 100% binary compatible way?'' The [[BinaryCompatibleDefaultMethods|newly written post]] provides the answer. Yes, [[BinaryCompatibleDefaultMethods|adding default methods to interfaces in a 100% binary compatible way]] is possible at the end! |
| - | binary compatible way?'' The [[BinaryCompatibleDefaultMethods|newly written post]] provides the answer. Yes, [[BinaryCompatibleDefaultMethods|adding default methods to interfaces in a 100% binary compatible way]] is possible at the end! | + | |
--[[User:JaroslavTulach|JaroslavTulach]] 06:10, 30 September 2020 (UTC) | --[[User:JaroslavTulach|JaroslavTulach]] 06:10, 30 September 2020 (UTC) | ||
| ←Older revision | Revision as of 06:10, 30 September 2020 | ||
| Line 2: | Line 2: | ||
<startFeed /> | <startFeed /> | ||
| + | |||
| + | ==== Adding [[DefaultMethods]] in a 100% [[BackwardCompatible]] Way! ==== | ||
| + | |||
| + | I took a part in a tweetting about [[BinaryCompatibleDefaultMethods|incompatibilities related to | ||
| + | CharSequence.isEmpty()]] over the weekend and I asked myself a simple question: ''Is it possible to add a default method in a 100% | ||
| + | binary compatible way?'' The [[BinaryCompatibleDefaultMethods|newly written post]] provides the answer. Yes, [[BinaryCompatibleDefaultMethods|adding default methods to interfaces in a 100% binary compatible way]] is possible at the end! | ||
| + | |||
| + | --[[User:JaroslavTulach|JaroslavTulach]] 06:10, 30 September 2020 (UTC) | ||
==== Never Update ([[API]]) Tests! ==== | ==== Never Update ([[API]]) Tests! ==== | ||
| ←Older revision | Revision as of 04:05, 24 January 2019 | ||
| Line 5: | Line 5: | ||
==== Never Update ([[API]]) Tests! ==== | ==== Never Update ([[API]]) Tests! ==== | ||
| - | Designing an API that shall last? Then [[Never update tests]]! The need to update tests is a sign of an [[ | + | Designing an API that shall last? Then [[Never update tests]]! The need to update tests is a sign of an [[incompatible]] change. |
--[[User:JaroslavTulach|JaroslavTulach]] 04:05, 24 January 2019 (UTC) | --[[User:JaroslavTulach|JaroslavTulach]] 04:05, 24 January 2019 (UTC) | ||
| ←Older revision | Revision as of 04:05, 24 January 2019 | ||
| Line 2: | Line 2: | ||
<startFeed /> | <startFeed /> | ||
| + | |||
| + | ==== Never Update ([[API]]) Tests! ==== | ||
| + | |||
| + | Designing an API that shall last? Then [[Never update tests]]! The need to update tests is a sign of an [[incompatibile]] change. | ||
| + | |||
| + | --[[User:JaroslavTulach|JaroslavTulach]] 04:05, 24 January 2019 (UTC) | ||
==== Never hold a lock when calling a foreign code! ==== | ==== Never hold a lock when calling a foreign code! ==== | ||
| ←Older revision | Revision as of 07:11, 2 August 2018 | ||
| Line 2: | Line 2: | ||
<startFeed /> | <startFeed /> | ||
| + | |||
| + | ==== Never hold a lock when calling a foreign code! ==== | ||
| + | |||
| + | Fighting with [[deadlock]]s is hard in normal code. In case of [[API]]s it is even harder. Yet, the advice is simple [[Deadlock|Never hold a lock when calling a foreign code]]. See the typical example rewritten to be [[deadlock]]-free in the dedicated [[deadlock]] page. | ||
| + | |||
| + | --[[User:JaroslavTulach|JaroslavTulach]] 07:11, 2 August 2018 (UTC) | ||
==== Shocking: [[Default Listener Methods]] ain't Dangerous! ==== | ==== Shocking: [[Default Listener Methods]] ain't Dangerous! ==== | ||