Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?
On Thu, Oct 17, 2019 at 4:54 PM Mike Schinkel wrote: > Before creating an RFC I wanted to get reactions to the idea of adding > FALLTHROUGH option to SWITCH/CASE for when the developer explicitly want > logic to fall through to the next case and does not want to use a BREAK. > > My simples motivation for this feature is that my IDE (PhpStorm) always > flags CASE statements w/o BREAKs because it cannot know when I intend for > the logic to fallthrough and not break. If there was an optional > FALLTHROUGH then my IDE could flag any CASE statements that do not have a > FALLTHROUGH or BREAK — which would indicate an error of my intent — and > avoid flagging all the situations where I intentionally want it to fall > through. > > Beyond that, this might also be useful for other static analysis tools > such as PhpStan. > Ust > Additionally it could be added in 8.0 and then in 8.1 flagged with a > warning when a CASE does not have one for the two, but only if people don't > object to this. While I know some on this list feel strongly that warnings > must come with to future plans to generate errors I would personally be > 100% okay if it indefinitely generated only a warning. > > In summary I want a mechanism to be allow me to explicitly indicate my > intent with respect to SELECT/CASE statements. What do you think? Is this > worthy of an RFC, or is there some reason a majority would object to such > an addition? > +1. It's 100% opt-in. People can keep using implicit fall-through, their own /* fallthrough */ comments, or the new token. There's virtually no overhead in the compile phase and it doesn't mess with the jump table optimizations. There's precedent for this desire in PHP static analyzers [1] as well as other major projects: eg, the Linux Foundation just completed a 2 year project to remove implicit fall-through in the Linux kernel [2] (*). That said, some questions: Do you envision this token accepting an optional argument, as break does, to fall-through multiple nesting levels? Eg: What do you envision the result of indicating fall-through to no subsequent case? Eg: Would a "pragma" (of sorts) be a part of the concept? [1]:https://github.com/phan/phan/issues/2550 [2]:https://lwn.net/Articles/794944/ (*) Fun trivia: PHP is mentioned in that LWN article about naming conventions.
Re: [PHP-DEV] Re: Adding explicit intent for SWITCH/CASE fall through?
At the case level, not the switch level.
Here is the code that I was working on that caused me to finally send this
message.
switch ( $new_name ) {
case 'portal_id':
case 'portalid':
$new_name = 'portalId';
break;
case 'form_id':
case 'formid':
$new_name = 'formId';
break;
case 'educationtype':
$update = false;
fallthrough;
case 'education':
$new_name = 'educationType';
if ( EducationTypes::is_edu_type_slug( $value ) ) {
$new_value = EducationTypes\Names::get( $value );
}
break;
default:
$update = false;
break;
}
(Note the code is from an iterative refactoring process where I will eventually
get rid of this specific code but in the short term I am trying to unify all
the terms into a single list rather than have a bunch of different names in the
code for the same thing. When iterative refactoring my emphasis is
understanding the logic and on on unifying the code and not on what is the best
architecture.)
> It sounds like a job for a static analysis comment:
>
> /** @DisableSwitchStatementFallthroughWarning */
Interesting. That feels more like static analysis tools use the only tool they
have — comments — since they can't change PHP, and not a good model for
language evolution.
My reaction is it feels rather inelegant. It would be a heck of a lot more to
type and a good bit harder to read. In my perfect world it would be part of
the language, not just a commenting convention.
Is there a a standardized list of these for PHP somewhere on php.net? I
googled and did not find any such list; maybe I am missing it?
I doubt we would want an option in the future for PHP to generate a warning
when this type of comment is missing? Key to this request is that PHP also
generates a warning when warnings are turned on during development.
Also, when reading code I tend to have "comment blindness" similar to how
people have "ad blindness" when browsing the web. Since comments are typically
not code and are often not maintained I don't trust them so only read comments
when the code is hard to decipher. In this case if I saw a missing break I
would assume the person intended it and might not realize there is a comment
indicating it. But YMMV.
> a token that would effectively no-op in all circumstances.
Is it really a no-op? I envisioned is a jump to the next case.
But I also saw that it was small enough scope I could probably use it to learn
how to author a patch for PHP.
BTW, GoLang has exactly what I am asking about:
https://github.com/golang/go/wiki/Switch#fall-through
-Mike
> On Oct 17, 2019, at 5:42 PM, Mark Randall wrote:
>
> On 17/10/2019 21:54, Mike Schinkel wrote:
>> Additionally it could be added in 8.0 and then in 8.1 flagged with a warning
>> when a CASE does not have one for the two, but only if people don't object
>> to this. While I know some on this list feel strongly that warnings must
>> come with to future plans to generate errors I would personally be 100% okay
>> if it indefinitely generated only a warning.
>
> Would you put this at switch level, or case level?
>
> Unless your plan is to redefine how switch works by default, which would be
> quite ambitious, I'm not sure it makes a great deal of sense to add a token
> that would effectively no-op in all circumstances.
>
> It sounds like a job for a static analysis comment:
>
> /** @DisableSwitchStatementFallthroughWarning */
> switch ($x) {
> case 1:
>$x = doSomething();
>
> case 2:
>doLaLaLaLa();
>break;
>
> default:
>doTralala();
> }
>
> --
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
[PHP-DEV] Re: Adding explicit intent for SWITCH/CASE fall through?
On 17/10/2019 21:54, Mike Schinkel wrote:
Additionally it could be added in 8.0 and then in 8.1 flagged with a warning
when a CASE does not have one for the two, but only if people don't object to
this. While I know some on this list feel strongly that warnings must come with
to future plans to generate errors I would personally be 100% okay if it
indefinitely generated only a warning.
Would you put this at switch level, or case level?
Unless your plan is to redefine how switch works by default, which would
be quite ambitious, I'm not sure it makes a great deal of sense to add a
token that would effectively no-op in all circumstances.
It sounds like a job for a static analysis comment:
/** @DisableSwitchStatementFallthroughWarning */
switch ($x) {
case 1:
$x = doSomething();
case 2:
doLaLaLaLa();
break;
default:
doTralala();
}
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?
Hi All, Before creating an RFC I wanted to get reactions to the idea of adding FALLTHROUGH option to SWITCH/CASE for when the developer explicitly want logic to fall through to the next case and does not want to use a BREAK. My simples motivation for this feature is that my IDE (PhpStorm) always flags CASE statements w/o BREAKs because it cannot know when I intend for the logic to fallthrough and not break. If there was an optional FALLTHROUGH then my IDE could flag any CASE statements that do not have a FALLTHROUGH or BREAK — which would indicate an error of my intent — and avoid flagging all the situations where I intentionally want it to fall through. Beyond that, this might also be useful for other static analysis tools such as PhpStan. Ust Additionally it could be added in 8.0 and then in 8.1 flagged with a warning when a CASE does not have one for the two, but only if people don't object to this. While I know some on this list feel strongly that warnings must come with to future plans to generate errors I would personally be 100% okay if it indefinitely generated only a warning. In summary I want a mechanism to be allow me to explicitly indicate my intent with respect to SELECT/CASE statements. What do you think? Is this worthy of an RFC, or is there some reason a majority would object to such an addition? Thanks in advance. -Mike
[PHP-DEV] Help with memory leak on zend_call_function
Hi all, I am working on this PR: https://github.com/php/php-src/pull/4797 It implements the ability to set a userland callback function that would allow or deny SQL queries in SQLite using its internal authorizer logic. This is a native feature of SQLite that is currently missing from the PHP extension. It's quite straightforward, but I could not find much documentation on zend_call_function and fci/fcc. So I just tried to find existing examples that did the same (calling a userland function callback from the C extension) and mostly used the one from libxml. So it works well, but I'm stuck on a memory leak, even though I'm using zend_fcall_info_args_clear. I'm not sure what's going on here and why. So if someone could take a look or point me in the right direction, that would be great :) Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline switch as alternative to nested inline conditional
On Wed, 16 Oct 2019 at 18:10, Bob Weinand wrote: > what's the concrete advantage of this syntax as opposed to the already > possible: > > $value = [ > A1 => A2, > B1 => B2, > ][expr()] ?? C; > What's the concrete advantage of switch over if-elseif? What's the concrete advantage of if blocks over conditional jumps? The primary answer in all three cases is surely "expressiveness". If I came upon code like that, it would take me a while to understand its intent - does $value end up as an array, or something else? what's the ?? there for, and when will expression C be used? Now, it may be that the task in question isn't common enough to deserve its own syntax, or you may not like the proposed syntax, but I think that's very different from coming up with lots of clever ways of writing something, and requiring new syntax to have a "concrete advantage" over each one. Regards, -- Rowan Tommins [IMSoP]
