> Am 18.09.2015 um 02:35 schrieb John Bafford <jbaff...@zort.net>:
>
>> On Sep 17, 2015, at 20:06, Bob Weinand <bobw...@hotmail.com> wrote:
>>
>>> Am 18.09.2015 um 01:52 schrieb John Bafford <jbaff...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
