Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124216
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <b8bb202c-c0e8-495e-bb7a-c81821669a58@app.fastmail.com>
In-Reply-To: 
 <CAKcc2m8jLyYkXH5fuJY=EGCFFCAfHUMVpEu3-KGev3E9fy_Z-A@mail.gmail.com>
References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net>
 <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com>
 <GV1PR01MB10526D0B220ED0AC9D1C17473C2DD2@GV1PR01MB10526.eurprd01.prod.exchangelabs.com>
 <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com>
 <CAJp_myXHSHD6+76gyOs=d+cfVgwCmpuhKMtYcVBM6b-i3Bf0WQ@mail.gmail.com>
 <fb56bb79-7e77-4b61-b247-a70a10d7103b@app.fastmail.com>
 <CAKcc2m8jLyYkXH5fuJY=EGCFFCAfHUMVpEu3-KGev3E9fy_Z-A@mail.gmail.com>
Date: Thu, 04 Jul 2024 12:48:21 +0200
To: "Ken Guest" <kguest@php.net>
Cc: "Matthew Weier O'Phinney" <mweierophinney@gmail.com>,
 "Stephen Reay" <php-lists@koalephant.com>,
 "Vincent de Lau" <vincent@delau.nl>,
 "PHP internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback]
 PHP User Modules - An Adaptation of ES6 from JavaScript)
Content-Type: multipart/alternative;
 boundary=f746141533f14ca7b0cf7664f020fac3
From: rob@bottled.codes ("Rob Landers")

--f746141533f14ca7b0cf7664f020fac3
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 4, 2024, at 12:37, Ken Guest wrote:
>=20
>=20
> On Thu, 4 Jul 2024 at 07:32, Rob Landers <rob@bottled.codes> wrote:
>> __
>>=20
>> My main feedback to PSR=E2=80=99s is that they are fundamentally brok=
en due to being outdated. The idea behind the standards is sound, but th=
ere are only a few PSRs that are applicable to today=E2=80=99s PHP. When=
 I look at creating new libraries today, PSR=E2=80=99s are a good inspir=
ation, but they probably shouldn=E2=80=99t be used in actual programs. H=
ere=E2=80=99s a short list of outdated standards I=E2=80=99ve collected =
over the last couple of years:
>>=20
>>  =E2=80=A2 7
>>  =E2=80=A2 11
>>  =E2=80=A2 15
>>  =E2=80=A2 18
>>  =E2=80=A2 20
>> Most of these breakdown if you start dealing with fibers, various new=
 scopes introduced by runtimes, new http standards, etc.=20
>>=20
>> Ergo, if you=E2=80=99ve run into these issues, you are likely incline=
d to stay as far away from PSR=E2=80=99s as reasonably possible and may =
have a negative view of them. However, for enterprise applications, PSR=E2=
=80=99s are a godsend. So they do have their uses, don=E2=80=99t get me =
wrong, but if you want to use technology newer than 2019-ish, you need t=
o avoid them; and this is a large part of why I say PSR-XX isn=E2=80=99t=
 a valid argument on this list.
>=20
> This is one of the reasons why we [FIG] now have the concept of PHP Ev=
olving Recommendations (PERs), which can be updated/evolved over time wi=
th multiple releases - instead of having having a succession of PSRs and=
 having to know which one supersedes another.
>=20
> The only example of this thus far is PER-CS for Coding Standards - ver=
sion 1 being the PER equivalent of PSR-12 and version 2 of PER-CS being =
an update addressing syntax in PHP that was not present when PSR-12, e.g=
. match, enums, attributes and all that other wonderful stuff.
> =20
> There is no reason why any current PSR can't be replaced with a PER eq=
uivalent - given a Working Group, time and focus.
>=20
> Except maybe PSR-8.
>=20
>=20
>=20
> --
> http://about.me/kenguest/

If I could have one to be a PER first, it would be the container interfa=
ce (PSR-11). When it was originally worked on, there was basically one l=
ifecycle of an object: a request. For almost all possible SAPIs, after t=
he request ended, everything was gone. Today, we basically have multiple=
 ones if you are using modern runtimes:
 1. Environment Scope: configuration that survives execution of the prog=
ram
 2. Global Scope: services/entities that can exist beyond the lifetime o=
f a request, but may or may not (depending on runtime)
 3. Request Scope: services/entities that should be unique for every req=
uest.
 4. Volatile Scope: services/entities that should be created every time =
they are injected.
Right now, these are all mixed into one giant container, that may or may=
 not be shared between requests, because that is the interface we have t=
o work with. It isn't great :| but it works, barely.

=E2=80=94 Rob
--f746141533f14ca7b0cf7664f020fac3
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Thu, Jul 4, =
2024, at 12:37, Ken Guest wrote:<br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><br></div><div><br></d=
iv><div class=3D"qt-gmail_quote"><div dir=3D"ltr" class=3D"qt-gmail_attr=
">On Thu, 4 Jul 2024 at 07:32, Rob Landers &lt;rob@bottled.codes&gt; wro=
te:<br></div><blockquote class=3D"qt-gmail_quote" style=3D"margin-top:0p=
x;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);paddin=
g-left:1ex;"><div class=3D"qt-msg-916498676836604871"><div><u></u><br></=
div><div><div><br></div><div>My main feedback to PSR=E2=80=99s is that t=
hey are fundamentally broken due to being outdated. The idea behind the =
standards is sound, but there are only a few PSRs that are applicable to=
 today=E2=80=99s PHP. When I look at creating new libraries today, PSR=E2=
=80=99s are a good inspiration, but they probably shouldn=E2=80=99t be u=
sed in actual programs. Here=E2=80=99s a short list of outdated standard=
s I=E2=80=99ve collected over the last couple of years:<br></div><div><b=
r></div><ul><li>7<br></li><li>11<br></li><li>15<br></li><li>18<br></li><=
li>20<br></li></ul><div>Most of these breakdown if you start dealing wit=
h fibers, various new scopes introduced by runtimes, new http standards,=
 etc.&nbsp;<br></div><div><br></div><div>Ergo, if you=E2=80=99ve run int=
o these issues, you are likely inclined to stay as far away from PSR=E2=80=
=99s as reasonably possible and may have a negative view of them. Howeve=
r, for enterprise applications, PSR=E2=80=99s are a godsend. So they do =
have their uses, don=E2=80=99t get me wrong, but if you want to use tech=
nology newer than 2019-ish, you need to avoid them; and this is a large =
part of why I say PSR-XX isn=E2=80=99t a valid argument on this list.<br=
></div></div></div></blockquote><div><br></div><div>This is one of the r=
easons why we [FIG] now have the concept of=20
PHP Evolving Recommendations (PERs), which can=20
be updated/evolved over time with multiple releases - instead of having =
having a succession of PSRs and having to know which one supersedes anot=
her.<br></div><div><br></div><div>The only example of this thus far is=20
PER-CS for Coding Standards - version 1 being the PER equivalent of PSR-=
12 and version 2 of PER-CS being an update addressing syntax in PHP that=
 was not present when PSR-12, e.g. match, enums, attributes and all that=
 other wonderful stuff.<br></div><div>&nbsp;<br></div></div><div>There i=
s no reason why any current PSR can't be replaced with a PER equivalent =
- given a Working Group, time and focus.<br></div><div><br></div><div>Ex=
cept maybe PSR-8.<br></div><div><br></div><div><br></div><div><div><br><=
/div><div><span class=3D"qt-gmail_signature_prefix">--</span><br></div><=
div dir=3D"ltr" class=3D"qt-gmail_signature"><div dir=3D"ltr"><a href=3D=
"http://about.me/kenguest/" target=3D"_blank">http://about.me/kenguest/<=
/a><br></div></div></div></div></blockquote><div><br></div><div>If I cou=
ld have one to be a PER first, it would be the container interface (PSR-=
11). When it was originally worked on, there was basically one lifecycle=
 of an object: a request. For almost all possible SAPIs, after the reque=
st ended, everything was gone. Today, we basically have multiple ones if=
 you are using modern runtimes:<br></div><ol><li>Environment Scope: conf=
iguration that survives execution of the program<br></li><li>Global Scop=
e: services/entities that can exist beyond the lifetime of a request, bu=
t may or may not (depending on runtime)<br></li><li>Request Scope: servi=
ces/entities that should be unique for every request.<br></li><li>Volati=
le Scope: services/entities that should be created every time they are i=
njected.<br></li></ol><div>Right now, these are all mixed into one giant=
 container, that may or may not be shared between requests, because that=
 is the interface we have to work with. It isn't great :| but it works, =
barely.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></=
div></body></html>
--f746141533f14ca7b0cf7664f020fac3--