Timeline for When should you create/destroy underlying object in a class that wraps it
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 27, 2014 at 14:38 | comment | added | Yam Marcovic | Indeed - but in a language without destructors, that's part of the contract when handling unmanaged resources, such as files. Otherwise, you might never close them as long as your process is alive, and most likely never in the time you want to. | |
| Sep 27, 2014 at 6:53 | history | edited | fstanis | CC BY-SA 3.0 | title more clear |
| Sep 26, 2014 at 21:25 | comment | added | fstanis | Wouldn't having a close() method in the first example (one with the constructor) allow the possibility of the object existing in an invalid state (as explained by @busy_wait in his answer)? | |
| Sep 26, 2014 at 20:42 | comment | added | Yam Marcovic | And, as a general direction, that the constructor approach is only useful so long as you have access to the concrete class. As soon as you start getting into interfaces (or dependency injection), that sort of interface can pose some problems. | |
| Sep 26, 2014 at 20:41 | comment | added | Yam Marcovic | I'd add gently, for the sake of completeness, that you still want a close() method even when you open it in the constructor. | |
| Sep 26, 2014 at 19:50 | answer | added | idoby | timeline score: 3 | |
| Sep 26, 2014 at 18:45 | answer | added | Silviu Burcea | timeline score: 0 | |
| Sep 26, 2014 at 18:30 | review | First posts | |||
| Sep 26, 2014 at 20:07 | |||||
| Sep 26, 2014 at 18:29 | history | asked | fstanis | CC BY-SA 3.0 |