Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125151
Date: Fri, 23 Aug 2024 12:56:32 -0400
To: Stephen Reay <php-lists@koalephant.com>
Cc: =?utf-8?Q?Rowan_Tommins_=5BIMSoP=5D?= <imsop.php@rwec.co.uk>, PHP
 internals <internals@lists.php.net>
Message-ID: <19ED3E60-FB1C-4691-B0F6-7BF3A569821B@getmailspring.com>
In-Reply-To: <68BD8107-9BBE-476B-B085-B340CB709A49@koalephant.com>
References: <68BD8107-9BBE-476B-B085-B340CB709A49@koalephant.com>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order
 (global, then local)
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66c8bf40_327b23c6_15341"
From: john@coggeshall.org (John Coggeshall)

--66c8bf40_327b23c6_15341
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



On Aug 23 2024, at 12:27 pm, Stephen Reay <php-lists@koalephant.com> wrote:
>
> The current inconsistencies between symbol types can be avoided in userland in a 100% consistent way. Import or qualify the symbols you use, all the time, and you have 0 inconsistencies or bizarreness in terms of what it used when.

So are you essentially arguing that we should put the burden on the majority of users, most of whom (documented by us or not) likely will have no idea what the problem is or potential consequences are? BC breaks happen. While I am all for avoiding BC breaks when possible, sometimes they make sense -- and I think this is a clear example of when it does.
I think you are exaggerating the impact of the BC break here. In fact Ilija measured the impact on the top 1000 composer packages:
https://gist.github.com/iluuu1994/4b83481baac563f8f0d3204c697c5551
> I was specifically pointing out that a small number of people complaining about this is a ridiculous reason to even consider the change.
That's one take. Another take is this is an easy win for a few percentage points bump in speed, with improved supply-chain security for composer packages that has a minimal impact on users.
> Great, how about the solution that doesn't have any BC, and works in every version back to 5.3?
By this logic, we should never introduce BC breaks.
> Great, so then we can resolve this whole thing by adding a footnote to the "Name resolution rules" page in the manual that (a) recommends using qualified names (i.e. prefix with a `\`) and (b) provides deeper details of the reasons for those who care.
From the perspective of program language _design_ (which is what we're talking about here), the goal is to create a language that helps the developer do something faster/better/easier, not do the wrong thing (slower code, etc.) by default and dump the responsibly for that on developers by expecting them to read a footnote buried in a doc. Especially when the justification is because there's concerns that code written in 2009 won't work anymore.

--66c8bf40_327b23c6_15341
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div class=3D=22gmail=5Fquote=5Fattribution=22>On Aug 23 2024, at=
 12:27 pm, Stephen Reay &lt;php-lists=40koalephant.com&gt; wrote:</div><b=
lockquote><div><br><div>The current inconsistencies between symbol types =
can be avoided in userland in a 100% consistent way. Import or qualify th=
e symbols you use, all the time, and you have 0 inconsistencies or bizarr=
eness in terms of what it used when.</div><br></div></blockquote><div><br=
><div>So are you essentially arguing that we should put the burden on the=
 majority of users, most of whom (documented by us or not) likely will ha=
ve no idea what the problem is or potential consequences are=3F BC breaks=
 happen. While I am all for avoiding BC breaks when possible, sometimes t=
hey make sense -- and I think this is a clear example of when it does.</d=
iv><br><div>I think you are exaggerating the impact of the BC break here.=
 In fact Ilija measured the impact on the top 1000 composer packages:</di=
v><br><div><a href=3D=22https://gist.github.com/iluuu1994/4b83481baac563f=
8f0d3204c697c5551=22 title=3D=22https://gist.github.com/iluuu1994/4b83481=
baac563f8f0d3204c697c5551=22>https://gist.github.com/iluuu1994/4b83481baa=
c563f8f0d3204c697c5551</a></div><br><blockquote>I was specifically pointi=
ng out that a small number of people complaining about this is a ridiculo=
us reason to even consider the change.</blockquote><br><div>That's one ta=
ke. Another take is this is an easy win for a few percentage points bump =
in speed, with improved supply-chain security for composer packages that =
has a minimal impact on users.</div><br><blockquote>Great, how about the =
solution that doesn't have any BC, and works in every version back to 5.3=
=3F</blockquote><br><div>By this logic, we should never introduce BC brea=
ks. </div><br><blockquote>Great, so then we can resolve this whole thing =
by adding a footnote to the =22Name resolution rules=22 page in the manua=
l that (a) recommends using qualified names (i.e. prefix with a =60=5C=60=
) and (b) provides deeper details of the reasons for those who care.</blo=
ckquote><br><div>=46rom the perspective of program language =5Fdesign=5F =
(which is what we're talking about here), the goal is to create a languag=
e that helps the developer do something faster/better/easier, not do the =
wrong thing (slower code, etc.) by default and dump the responsibly for t=
hat on developers by expecting them to read a footnote buried in a doc. E=
specially when the justification is because there's concerns that code wr=
itten in 2009 won't work anymore.</div><br></div>
--66c8bf40_327b23c6_15341--