Re: Let's discuss enums!

> On Sep 17, 2015, at 20:06, Bob Weinand <bobwei9@hotmail.com> wrote: > >> Am 18.09.2015 um 01:52 schrieb John Bafford <jbafford@zort.net>: >> >> If we’re bikeshedding, one feature I would really like to see, with typehinting, is >> warnings if all cases of an enum aren’t handled in a switch. So, for example, given our example >> Weekdays enum, if I wrote this code: >> >> switch(Weekday $someWeekday) { >> case Weekday::MONDAY: break; >> case Weekday::TUESDAY: break; >> } >> >> By providing the typehint, I’m indicating that I want to get a warning/error that the >> switch does not cover all enum values. This would be very handy if an enum value is added after >> initial development and someone misses a switch statement in cleanup. >> >> The typehint would also allow generating a warning if someone did something like >> >> switch(Weekday $someWeekday) { >> //case … all the weekdays: break; >> case ‘I am not a Weekday’: echo ‘Generate a fatal error here because string is not a >> Weekday.’; >> } > > So, you mean like an implicit > default: throw Error("Unhandled enum value Weekday::FRIDAY"); > > Possible, but then you also just can add > default: assert(0); > instead of a typehint. > > At compile-time won't be really possible, as, when the switch is encountered, the enum > might not yet have been loaded. That's one of the consequences of PHP's lazy inclusion > system... Compile-time might not be possible, true, but at least this would provide for runtime checks, and the benefit of explicitly stating intention is that intention is explicitly stated. Also, it would allow the sort of errors I’m proposing be generated to all be standardized across all applications, which would allow fancy error handlers, such as with Symfony, to offer helpful context-specific suggestions. Also, it’d provide static analyzers additional information by which to provide correctness alerts. -John