Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111615
Message-ID: <3303DAF3-B31D-434F-905B-49D221111F9E@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_DA645E92-069D-405F-8840-09AC5044FA4F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Tue, 18 Aug 2020 16:08:04 -0400
In-Reply-To: <CAEPJdu=inqUNTXgbtu8V=oJ4-M+beeD5m3v=FoEwyPJ+YtwdHQ@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
To: Benjamin Eberlei <kontakt@beberlei.de>
References: <alpine.DEB.2.23.453.2008100935570.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB65356FCC029CD06F49F528A0DE420@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CABdc3WobP1HSRwcujd4=o4wv3QUp7gDT12KmMRQU1_wLj4YLuQ@mail.gmail.com>
 <BYAPR05MB65351C807797676BB08D8BDCDE430@BYAPR05MB6535.namprd05.prod.outlook.com>
 <5cc837df-ab47-628a-d29b-46d7933be973@gmx.net>
 <BYAPR05MB653522F9123B59F7E066BDB8DE430@BYAPR05MB6535.namprd05.prod.outlook.com>
 <3A7CECC3-CDEE-4852-BF4B-4EC7CA1BD538@pmjones.io>
 <CAAKU0u=VYh7D+XJ93dDdAxdJ8nEU8iPfeN0f=Xv9Qm=cCQKX6w@mail.gmail.com>
 <BN8PR05MB6532D19BEA11F44BAAD3FDD3DE400@BN8PR05MB6532.namprd05.prod.outlook.com>
 <CAESVnVp5NHKKpMHt_7AAO8P9L2vL8UN4ynD5K4d9f23Jvr+s2A@mail.gmail.com>
 <alpine.DEB.2.23.453.2008141902160.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB65352D21FAA7EA37A9A0C37FDE400@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CABdc3Wrd+WECJOXCmYu0Gq5VttVtTkDoO=-9SEP_+-p=qoNB4w@mail.gmail.com>
 <7d6c42a4-53cd-5e38-4ffc-02fe490d66a3@gmx.net>
 <DM6PR07MB6618E0D524F8E7EDE57B87C2F9410@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAJvSBVPgXXLL0=fN2e3c=+P_x58kE5jsYVRMpGN5yvmWEcCP6g@mail.gmail.com>
 <d4b885c812522de0b014380fffa3dddee52f9cf3f8c9629bfa0d31fbaf18f362@mahalux.com>
 <CAG9XoMRiQSjUPUodDXVCSGwgAC-BhdXVH-vizDRcjgvLt+KKpQ@mail.gmail.com>
 <CAJmjfvVNDRCBOUoaSTPA=Lyhi201ios1uNy_cmBmZ++bGaRvpw@mail.gmail.com>
 <CAEPJdu=65Sc+ixyJm52iwMaO3EzX4M4Xm5XMRAtt107xixBVBA@mail.gmail.com>
 <CAJmjfvWcmnjhZ_A6uaZaj3jFr-HPUPOnGm0mdSOLr3Lk094i0Q@mail.gmail.com>
 <CAEPJdukEgrw0bwPc6EVEGSTN20Rvk70HHMSeZ=c=c5Xu+LPfiQ@mail.gmail.com>
 <CAJmjfvUOF2GvLjapOFqcEuj4ORkiW92d7gq0gF30hx+mxMs0wA@mail.gmail.com>
 <CANeKSiQU31ZGYTMCwpQOkUFRwYGHaK=-kibcFswNGb6zE-qhMA@mail.gmail.com>
 <9A07334F-1A55-4E7D-88B5-7E6BABFB5E81@newclarity.net>
 <CAEPJdu=inqUNTXgbtu8V=oJ4-M+beeD5m3v=FoEwyPJ+YtwdHQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_DA645E92-069D-405F-8840-09AC5044FA4F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Aug 18, 2020, at 6:54 AM, Benjamin Eberlei <kontakt@beberlei.de> =
wrote:
>=20
> On Tue, Aug 18, 2020 at 12:36 AM Mike Schinkel <mike@newclarity.net =
<mailto:mike@newclarity.net>> wrote:
> I have been following all the lengthy discussions on this topic hoping =
the list would come to consensus. And I had been hoping someone would =
call the following question but since no one else has here goes.
>=20
> The concept of adding attributes to PHP seemed to sail to acceptance =
but, if you count the original RFC there have been three (3) different =
RFCs each with the goal of setting or changing the decided syntax alone.
>=20
> For every syntax proposed there seems to be a contingent of people who =
are deeply troubled by it. Given that once a syntax lands in an official =
release of PHP there are not take backs, moving forward with any syntax =
where people are so divided seems like a really bad idea.=20
>=20
> If we care about future developers being happy enough with the =
decisions made about PHP to continue choosing PHP that I would think it =
would be incumbent upon us to find a syntax with a greater level of =
buy-in.
>=20
> Should we not:
>=20
> 1. Postpone inclusion of attributes until PHP 8.1 to ensure that we =
get a syntax that is reasonable acceptable to large segment of =
stakeholders?
>=20
> All the technically complex decisions are done, tested and decided. =
The syntax question is still open, but not critical from a technical =
implementation POV. All patches regardless of syntax are extremely =
similar, just replacing symbols. The non-technical implications and =
future related questions are what is up for decision. The arguments for =
or against these categories are by now driving in circles. Postponing to =
8.1 does therefore not bring additional value. A decision has to be made =
and we have enough time for that.
>=20
> 2. Optionally have an RFC to ask people to vote on disputed =
principles, such as "Are ending delimiters important and thus are they =
required for any selected syntax?"
>=20
> By voting for a syntax, these questions are answered implicitly.

Then may I please be allowed to add another option (or two) to the RFC, =
in hopes that it will be disliked less by everyone that the level of =
dislike a set of people have for every option?

I propose we utilize the "use" command but with required parenthesis =
using examples from my code where I previously simulated attributes:

// class attribute use
use PostType('abc_product'),
   TemplateVariable('product'),
   VirtualReadonly('id'),
   VirtualReadonly('name');
// method attribute use
use PrimaryKey();
An option to the above is we utilize the "use" command w/o required =
parenthesis but w/attribute modifier, although this is not my =
preference:
// class attribute use
use attribute PostType('abc_product'),
   TemplateVariable('product'),
   VirtualReadonly('id'),
   VirtualReadonly('name');
// method attribute use
use attribute PrimaryKey;
I have prepared a longer example as a Gist:

https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8 =
<https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8>

Appropriateness
---------------------

The second option is similar to "use function " so while it is not =
exactly the same, "use" is utilized by three contexts already, two (2) =
of them w/o a modifier:

1.) providing a local name for a namespace,
2.) providing a local name for a function, and=20
3.) what is effectively an include() for a trait.=20

The semantics of "use" works for attributes =E2=80=94 i.e. "Use this =
attribute for the following declaration" =E2=80=94 and having a 4th type =
of use seems like it would fit nicely into the existing language.

I would suggest viewing all the different syntaxes to see who "use =
AttrFunc()" compares in terms of readability:

https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8 =
<https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8>

Benefits
-----------
1. Short; three (3) characters that =E2=80=94 importantly =E2=80=94 DO =
NOT require use of the shift key (which my carpal tunnel would be =
thankful for.).=20

	1a. The 2nd options should be easy to type with an IDE/editor =
that supports macros
	1b. For example in PhpStorm you could assign ua<tab> to expand =
to "use attribute "

2. Has a closing delimiter, the semi-colon.

3. Supports grouping, using commas just like other uses of the "use" =
command.

4. Forward compatible in PHP 7 (I think.)

5. Uses existing T_USE attribute.

6. (I do not know if it would change the lexing of remaining tokens)

7. Does not prevent the nesting of attributes in the future as braces =
could be used as they currently are with traits

-Mike


--Apple-Mail=_DA645E92-069D-405F-8840-09AC5044FA4F--