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 motiva
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'
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 t
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) alway
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
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
