Timeline for What are the disadvantages of self-encapsulation?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 4, 2019 at 21:34 | comment | added | Errorsatz | Why allow setAttribute(null) if it's not valid for the attribute to be null? If non-null was asserted there (and an appropriate value set in the constructor), then the attribute can be used directly with no chance of being null. | |
| Jul 11, 2015 at 16:40 | answer | added | supercat | timeline score: 0 | |
| Nov 14, 2013 at 18:06 | vote | accept | Dave Jarvis | ||
| Nov 14, 2013 at 18:05 | history | edited | Dave Jarvis | CC BY-SA 3.0 | added 37 characters in body |
| Nov 13, 2013 at 17:37 | history | edited | Dave Jarvis | CC BY-SA 3.0 | added 5 characters in body |
| Nov 12, 2013 at 21:35 | comment | added | Dave Jarvis | The hypothesis is that using class-scoped variables directly results in code that crashes more often than using variables indirectly (and consistently) via accessor methods that force all uninitialized variables to be initialized immediately prior to use. In the example shown, calling setAttribute( null ) will cause the attribute's value to be re-initialized prior to use (e.g., makes a database call to find the current value). | |
| Nov 12, 2013 at 20:12 | answer | added | Karl Bielefeldt | timeline score: 9 | |
| Nov 12, 2013 at 19:41 | comment | added | Dan Pichelman | If I'm reading this correctly, you're asserting that nulls should be considered harmful and never used? Would self-encapsulation prevent the perceived need to test for if getAttribute() == defaultValue? | |
| Nov 12, 2013 at 19:13 | history | asked | Dave Jarvis | CC BY-SA 3.0 |