Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107570
Message-ID: <D7C2364B-DA8F-4739-B18E-05D0A841872B@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A941E84F-90FB-476F-ACE2-5C6ED6D62B30"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 17 Oct 2019 18:07:22 -0400
In-Reply-To: <5da8e051.1c69fb81.b05ef.ef7dSMTPIN_ADDED_MISSING@mx.google.com>
Cc: internals@lists.php.net
To: Mark Randall <marandall@php.net>
References: <929062F1-E83F-4D81-B2C6-3916B744E101@newclarity.net>
 <5da8e051.1c69fb81.b05ef.ef7dSMTPIN_ADDED_MISSING@mx.google.com>
Subject: Re: [PHP-DEV] Re: Adding explicit intent for SWITCH/CASE fall
 through?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_A941E84F-90FB-476F-ACE2-5C6ED6D62B30
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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 =3D 'portalId';
      break;
   case 'form_id':
   case 'formid':
      $new_name =3D 'formId';
      break;
   case 'educationtype':=20
      $update =3D false;
      fallthrough;
   case 'education':
      $new_name =3D 'educationType';
      if ( EducationTypes::is_edu_type_slug( $value ) ) {
         $new_value =3D EducationTypes\Names::get( $value );
      }
      break;
   default:
      $update =3D 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:
>=20
> /** @DisableSwitchStatementFallthroughWarning */

Interesting. That feels more like static analysis tools use the only =
tool they have =E2=80=94 comments =E2=80=94 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.=20

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?=20

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. =20


> 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:=20

	https://github.com/golang/go/wiki/Switch#fall-through


-Mike


> On Oct 17, 2019, at 5:42 PM, Mark Randall <marandall@php.net> wrote:
>=20
> 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.
>=20
> Would you put this at switch level, or case level?
>=20
> 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.
>=20
> It sounds like a job for a static analysis comment:
>=20
> /** @DisableSwitchStatementFallthroughWarning */
> switch ($x) {
>  case 1:
>    $x =3D doSomething();
>=20
>  case 2:
>    doLaLaLaLa();
>    break;
>=20
>  default:
>    doTralala();
> }
>=20
> --
> Mark Randall
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20


--Apple-Mail=_A941E84F-90FB-476F-ACE2-5C6ED6D62B30--