Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113759
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
In-Reply-To: <E954BC4E-18A4-431E-8CB2-D4DB34EE55E5@newclarity.net>
Date: Thu, 25 Mar 2021 01:49:33 -0400
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <32A831EE-02AC-466D-8A9F-38F463095892@newclarity.net>
References: <44ac7866-75ef-44ab-a5f9-4e571652b5e6@www.fastmail.com>
 <21C66BCC-A77D-48B0-A653-9D65ADF06A3B@newclarity.net>
 <CAAKU0u=E7n5Y7H68cKBjGyv82yOsRe0+C2w6Ef=EsM-SaBu=Bg@mail.gmail.com>
 <E954BC4E-18A4-431E-8CB2-D4DB34EE55E5@newclarity.net>
To: Levi Morrison <levi.morrison@datadoghq.com>
Subject: Re: [PHP-DEV] [RFC] Short functions, take 2
From: mike@newclarity.net (Mike Schinkel)

> On Mar 24, 2021, at 11:22 PM, Levi Morrison via internals =
<internals@lists.php.net> wrote:
>=20
> On Wed, Mar 24, 2021 at 8:02 PM Mike Schinkel <mike@newclarity.net> =
wrote:
>>=20
>>> On Mar 24, 2021, at 8:39 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>>>=20
>>> As requested, splitting off the short-functions RFC to its own =
thread.
>>>=20
>>> https://wiki.php.net/rfc/short-functions
>>>=20
>>> In response to the feedback that the savings in typing volume is =
small, that's true but also not the main point.  The main point is to =
allow and encourage functions to be written an in "expression style", =
that is, as actual functions and not procedures.  As the RFC notes, such =
use cases are increasing, and is likely to increase in PHP, and that's =
overall a good thing for the language.  It fits well with a number of =
recent RFCs both passed and proposed, and makes writing functional-style =
code much more natural.
>>=20
>> I like it.
>>=20
>> I hope this passes, and would vote for it if I had a vote.
>>=20
>> -Mike
>>=20
>> P.S. I do find myself lamenting that while this FRC makes code more =
concise it does not do anything to reduce the (IMO overly) verbose =
nature of method declarations that require both a visibility modifier =
and the function keyword. And while I know you just stated that =
conciseness in not a main goal, it is still a benefit of this proposal.
>>=20
>> It would be much nicer if we could indicate in fewer characters what =
the visibility modifier and the function keyword currently denote. Yes, =
that could be addressed in another RFC, but it could also be addressed =
in this one =E2=80=94 assuming there was a will do to so =E2=80=94 so =
now felt like a good a time as any to bring it up.
>>=20
>> Assuming others besides just me would like to see function signatures =
be made less verbose and would like to see some proposed alternatives, =
please ask and I will happily follow up with some ideas.
>=20
> Drop "public", as it is unnecessary. I never understood why
> PSR-whatever decided to always require it, when not all projects
> agreed on that, and there are actual arguments to put it only when
> overriding visibility (you see it only when it matters).

I have always understood the reason for `public` was that specifying it =
indicates that the developer was making an explicit statement about =
visibility. Of course with many developer's propensity for copy-paste =
and code generation, I am not sure that argument is as sound as it might =
first appear.

I can think of two (2) approaches to minimize verbosity and address =
visibility here.  Consider this code:

class Product {
   private Product $parent;
   private string $name;
   private int $counter;
   public function getName():string { return $this->name; }
   protected function getParent():Product { return $this->parent; }
   private function getCounter():int { return $this->counter; }
}

The first approach would be to make the use of the "function" keyword =
*optional* because, unless I am wrong, it should be unambiguous from a =
parser perspective:

class Product {
   private Product $parent;
   private string     $name;
   private int          $counter;
   public getName():string           =3D> $this->name;=20
   protected getParent():Product =3D> $this->parent;
   private getCounter():int           =3D> $this->counter;=20
}

The second approach =E2=80=94 which I would much prefer, but I doubt =
many others in the PHP world will =E2=80=94 is to use a "method" keyword =
and to draw inspiration from GoLang regarding visibility where leading =
uppercase method names are public, leading lowercase names are =
protected, and leading underscore names are private. =20

class Product {
   property Product $_parent;
   property string     $_name;
   property int          $_counter;
   method GetName():string     =3D> $this->_name;=20
   method getParent():Product =3D> $this->_parent;
   method _getCounter():int     =3D> $this->_counter;=20
}

We could also do the same thing with properties by introducing a =
"property" keyword, but I digress as shown in the second approach, but I =
digress...

Anyway, both of these two approaches would be backward compatible I =
think =E2=80=94 except the syntax of the second approach would not allow =
for revising existing classes to the new syntax without also updating =
their calling code =E2=80=94 but IMO either would be a nice addition to =
the short function RFC, or possibly an RFC of its own assuming there =
were enough others who would like to see the same?

> Anyway, it's
> not that important, as I don't have to do what PSR-whatever decided.
> Instead of writing this:
>=20
> ```
> class A
> {
>  public function method($arg1)
>  {
>    return expr($arg1);
>  }
> }
> ```
>=20
> I can write this:
>=20
> ```
> class A {
>  function method($arg1) { return expr($arg1); }
> }
> ```

Honestly, I always omit "public" whenever I have the choice, too.

But there is always a lot of "other-people's code" to read and =
understand, much of which uses PSR-12.

If there were a better syntax for visibility =E2=80=94 such as proposed =
above =E2=80=94 then maybe a revised PSR could be released to recognize =
the newer syntax?

> To be quite honest, I like putting statements on a single line as long
> as they fit in whatever column limit the project uses. My
> .clang-format has been doing this for my C code and I've grown quite
> fond of it; there is real value in seeing more actual code on a page
> at a time, and I don't feel like it's too cramped.

Yes, I'd like to see more code on the page too!  But I would also like =
more whitespace so that there will be less of the non-whitespace to have =
to mentally process.

-Mike