7 ms·
It still provides some of the same ergonomics. You can put away the mental cheat-sheet ("1: gold, 2: silver...."). Your IDE can find all uses of BookTypeId.Gol
by pradocchia 12y ago
It still provides some of the same ergonomics. You can put away the mental cheat-sheet ("1: gold, 2: silver...."). Your IDE can find all uses of BookTypeId.Gold(), rather than textual occurrences of "1". Etc.
The static quality of enums is only one of their features, and sometimes a hindrance, and it good to have other options.
- andrea_s 12y agosure, but I can't see how this is supposed to increase discoverability of the API... I see "here is something that looks like an enum, and its possible values are gold, silver and bronze. But you can also give 10, 42 or any number as a value and it will still work". I don't mean to be overly critical (clearly this approach has worked well for the author), but I am a bit unsure about the perceived benefits.
- pradocchia 12y agoYeah, I'm not sure how much it increase discoverability, plus users pay the cognitive cost of quirky patterns. I might have used an enum plus a second constructor to wrap the explicit conversation. I guess it depends on what's going on in the rest of the API.