Timeline for Using a loose array just to specify the object properties
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 15, 2017 at 22:50 | comment | added | Igor Soloydenko | @Iwrestledabearonce yes, it would work too, and do the same thing, yet looks dirty solution to me. Similarly, I'm not a big fan of in-place state changes generally, but that's preferential and I don't know the OP's context. | |
| Dec 15, 2017 at 22:43 | comment | added | Igor Soloydenko | @mike you're right. I overlooked the null check. | |
| Dec 15, 2017 at 22:34 | comment | added | Mike Brant | @IgorSoloydenko This is idempotent as you are only writing keys where current property state is null. This state would not exist once initial saturation has occurred. | |
| Dec 15, 2017 at 3:53 | comment | added | I wrestled a bear once. |
^ I thought about this initially as well. I think if I were to use this a quick one-off, adding delete this.decorateResults; to the end of the method would suffice.
|
|
| Dec 14, 2017 at 22:08 | comment | added | Igor Soloydenko | Will it be safe to call this function more than once? (Is it idempotent?) I think, it's not, so I'd prefer this function not to be a part of the object itself, and also name it the way it highlights the fact it is unsafe to call many times. Alternatively, return a new object with the decorated fields, but this changes the way function is used, which may not be desired. So, I like the original code/bear-wrestler's answer better. | |
| Dec 14, 2017 at 21:17 | history | answered | Mike Brant | CC BY-SA 3.0 |