Timeline for The Don't Repeat Yourself (DRY) principle in documentation
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 27, 2021 at 12:00 | comment | added | BreakingGnus | It is kind of a reversal of immutability: make as many copies of something as you like if it will not be changing. | |
| Jun 26, 2021 at 14:41 | comment | added | Doc Brown | @Ferrybig: when I get you right, your critics seem to be badly worded. I guess wanted to tell me that the (formerly) first bullet point is still valid today, not that it is invalid. | |
| Jun 26, 2021 at 6:08 | history | edited | Doc Brown | CC BY-SA 4.0 |
added an introductory paragraph about non-DRY-ness of the example
|
| Jun 25, 2021 at 15:23 | comment | added | Ferrybig |
Your first bullet point is invalid, even with modern java generic, you cannot make only a single method. A short[] is not an Object[]. Even if you wanted to make a method(ignoring the horrible performance, you would fail)
|
|
| Jun 25, 2021 at 12:14 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 542 characters in body
|
| Jun 25, 2021 at 11:58 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 18 characters in body
|
| Jun 25, 2021 at 8:34 | comment | added | Voo | (That said I agree with the wider point about defining cross-cutting concerns only once). | |
| Jun 25, 2021 at 8:30 | comment | added | Voo | I don't agree that this is a rare example. Yes the exact circumstance is rare, but in a language without default values for parameters (or languages like C# where using default parameters is ill-advised for compat reasons in frameworks and libraries) having overloads that provide defaults for some values is very common. You could link to the method that provides all parameters and rely on the documentation there, but that makes for an awful user experience (I want to see the documentation for the parameters a method takes without having to jump around!). | |
| Jun 25, 2021 at 7:02 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 149 characters in body
|
| Jun 25, 2021 at 4:45 | comment | added | Doc Brown | @PaŭloEbermann: as I wrote, the problem today is not the lack of generics, but performance (my second point on the list). | |
| Jun 24, 2021 at 22:12 | comment | added | Paŭlo Ebermann |
The problem is not the lack of generics, but that Java still treats primitive types as something separate from reference types, so it needed separate methods (or an untyped method, like the old System.arraycopy, which just takes an Object (which must be an array of some kind)).
|
|
| Jun 24, 2021 at 20:46 | comment | added | Deduplicator | Hm. These are all arrays of primitive types, not of references. Can Java generics handle them now? | |
| Jun 24, 2021 at 16:45 | history | edited | Doc Brown | CC BY-SA 4.0 |
slightly improved
|
| Jun 24, 2021 at 14:03 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 313 characters in body
|
| Jun 24, 2021 at 12:17 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 16 characters in body
|
| Jun 24, 2021 at 12:04 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 16 characters in body
|
| Jun 24, 2021 at 11:57 | history | answered | Doc Brown | CC BY-SA 4.0 |