Timeline for Object vs Primitive: Not use long primitive because... the default value is zero?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 22, 2018 at 14:34 | comment | added | Neil | @Deduplicator The "complexity" of using a boxed long is the very same reason why it'd be an advantage, as only pointers can be null. Uniform handling until you need to know that it hasn't been initialized, then you need to write special cases for when it is 0. That's not uniform handling. | |
| Mar 22, 2018 at 14:29 | comment | added | Deduplicator | @Neil As I wrote, uniform handling and efficiency are the two main reasons to avoid the complexity of using a pointer to a wrapper and using a primitive instead. | |
| Mar 22, 2018 at 13:54 | comment | added | Neil | Or you could simply make the L in long uppercase instead of lowercase. Why do anything more complex? What advantage do you stand to gain by not failing fast? | |
| Mar 22, 2018 at 13:51 | comment | added | Deduplicator | @Neil You could add a hook to the DB to make sure it doesn't allow creating an order with ID 0. Or you could do that in the DB access layer. Or, you know, as the ID will be an auto-numbered primary-id-column, you leave setting the id to the db to avoid race-conditions. | |
| Mar 22, 2018 at 7:59 | comment | added | Neil | @Deduplicator Assume for a second you're using an Order instance with erroneously id 0 due to a mistake in your program. So you check for the existence of this order instance in your database and none found (correctly so, as all Orders in your database have postive ids). Since it doesn't exist, you decide to create it, thereby effectively creating Order with id 0. Your assumption that Orders in your database have positive ids is no longer correct, but the error is not immediate. You test it and see no problems, and then pass it to the client a week later. Bug created. | |
| Mar 21, 2018 at 22:09 | comment | added | Deduplicator | @ShadowCreeper: The nice thing about designating zero as a sentinel value is that in the vast majority of places treating it as special is either a bad idea or just make-work anyway. | |
| Mar 21, 2018 at 22:04 | comment | added | Shadow Man | I wouldn't say "nothing wrong" with using magic numbers to represent an "unset" state. I would say that sometimes it is a necessary evil, but in general, explicit unset state makes your code less error prone. It is easy to forget to check for the magic values and treat the number as real, especially using the code months down the line when the magic numbers are no longer at the front of your mind. | |
| Mar 21, 2018 at 20:57 | history | answered | Deduplicator | CC BY-SA 3.0 |