Re: Let's discuss enums!

> Am 18.09.2015 um 02:35 schrieb John Bafford <jbafford@zort.net>: > >> 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 Static analyzers etc. all can look at the cases and conclude that the type indeed should have been of a certain Enum. I don't really see a particular advantage here. And for the run-time checks, just add a default: assert(0); as said. I don't see loads of benefits from this extra syntax. Also, as said, I'd pretty much prefer that to be separated out in a different RFC as it isn't crucial to the Enum feature itself. Bob