Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125162
Date: Fri, 23 Aug 2024 14:37:39 -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: <931B9F3E-6630-4F6A-9822-1BAC81F0643A@getmailspring.com>
In-Reply-To: <6C127753-4AA4-424A-BCD4-BD4CA6FA1DB3@koalephant.com>
References: <6C127753-4AA4-424A-BCD4-BD4CA6FA1DB3@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="66c8d6f3_19495cff_15341"
From: john@coggeshall.org (John Coggeshall)

--66c8d6f3_19495cff_15341
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



On Aug 23 2024, at 1:46 pm, Stephen Reay <php-lists@koalephant.com> wrote:
>
>
> The claims about "security" because a function you defined (or included via a package) is resolved in place of a global one are irrelevant. If you're including compromised code in your project, all bets are off.
I have plenty of experience behind why I disagree with your dismissal here, but I'm not going to debate it with you.
> > 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.
>
> Please be specific what you mean by "this". The original proposal by Ilija provides a constant BC break over time, whenever a new global function is introduced.
I don't think we're piling in functions all the time here -- and that's why we have deprecation notices when we do so we can warn users to rename a conflicting function.
>
> Great, so 0.24% of public packages represented, and 0% of private code represented. That certainly seems representative.
Honestly, statistically it actually is fairly meaningful and representative. I have serious doubts if you went from 1000 to 10000 you'd see much change (and would welcome that information if I'm wrong).
>
> You've also missed the other aspect here, which I mentioned earlier: namespaced function usage is low because the language hasn't traditionally supported it anywhere near as well as namespaced classes. There have been multiple people proclaiming recently that "static utility classes" are the 'wrong' approach, that people should use namespaced functions in their code. There are two active RFCs about function autoloading.
>
> This change would at best, make those functions slower to use within the same namespace, and at worst, more work, with a brand new inconsistency, to use within the same namespace.
The fact that functions have not been widely embraced as you argue would be an argument for having this debate now, rather than later after further adding to the complexity.
>
> The change we're talking about is in the range of maybe 2-4%, and is 100% solvable in userland - and has been for those 15 years, in a way that has zero impact on developers using the language to write their own functions, and is consistent with the way other symbol lookups (e.g. classes) work. I'll concede you one point. A footnote is clearly not important enough for a 2% performance benefit. Let's make it the subtext on the header of ever php.net (http://php.net) page, just to make sure people know.
By this logic we shouldn't have touched list , nor should we ever add any functionality that can't be implemented in userspace using existing tools. E.g. array_column
> I'm honestly not even sure where to begin here. If you add a namespaced function to your code, and call it from within that namespace, it will run. That's literally by design. If that is somehow surprising to you, I'd suggest the aforementioned name resolution page in the php manual. It's not exactly long, you can probably read it quicker than this email.
You say it's by design, I say it's a bad design and should be fixed.
--66c8d6f3_19495cff_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=
 1:46 pm, Stephen Reay &lt;php-lists=40koalephant.com&gt; wrote:</div><bl=
ockquote><div><br><br><div>The claims about =22security=22 because a func=
tion you defined (or included via a package) is resolved in place of a gl=
obal one are irrelevant. If you're including compromised code in your pro=
ject, all bets are off.</div></div></blockquote><br><div>I have plenty of=
 experience behind why I disagree with your dismissal here, but I'm not g=
oing to debate it with you.</div><br><blockquote><div><blockquote><div><d=
iv><div>BC breaks happen. While I am all for avoiding BC breaks when poss=
ible, sometimes they make sense -- and I think this is a clear example of=
 when it does.</div></div></div></blockquote><div><br></div><div>Please b=
e specific what you mean by =22this=22. The original proposal by Ilija pr=
ovides a constant BC break over time, whenever a new global function is i=
ntroduced.</div></div></blockquote><br><div>I don't think we're piling in=
 functions all the time here -- and that's why we have deprecation notice=
s when we do so we can warn users to rename a conflicting function.</div>=
<br><blockquote><div><div><br></div><div>Great, so 0.24% of public packag=
es represented, and 0% of private code represented. That certainly seems =
representative.</div></div></blockquote><br><div>Honestly, statistically =
it actually is fairly meaningful and representative. I have serious doubt=
s if you went from 1000 to 10000 you'd see much change (and would welcome=
 that information if I'm wrong).</div><br><blockquote><div><br><div>You'v=
e also missed the other aspect here, which I mentioned earlier: namespace=
d function usage is low because the language hasn't traditionally support=
ed it anywhere near as well as namespaced classes. There have been multip=
le people proclaiming recently that =22static utility classes=22 are the =
'wrong' approach, that people should use namespaced functions in their co=
de. There are two active R=46Cs about function autoloading.</div><div><br=
></div><div>This change would at best, make those functions slower to use=
 within the same namespace, and at worst, more work, with a brand new inc=
onsistency, to use within the same namespace.</div></div></blockquote><br=
><div>The fact that functions have not been widely embraced as you argue =
would be an argument for having this debate now, rather than later after =
further adding to the complexity.</div><br><blockquote><br></blockquote><=
blockquote><div>The change we're talking about is in the range of maybe 2=
-4%, and is 100% solvable in userland - and has been for those 15 years, =
in a way that has zero impact on developers using the language to write t=
heir own functions, and is consistent with the way other symbol lookups (=
e.g. classes) work. I'll concede you one point. A footnote is clearly not=
 important enough for a 2% performance benefit. Let's make it the subtext=
 on the header of ever <a href=3D=22http://php.net=22 title=3D=22http://p=
hp.net=22>php.net</a>&nbsp;page, just to make sure people know.</div></bl=
ockquote><br><div>By this logic we shouldn't have touched <code>list</cod=
e>&nbsp;, nor should we ever add any functionality that can't be implemen=
ted in userspace using existing tools. E.g. <code>array=5Fcolumn</code>&n=
bsp;</div><br><blockquote><div>I'm honestly not even sure where to begin =
here. If you add a namespaced function to your code, and call it from wit=
hin that namespace, it will run. That's literally by design. If that is s=
omehow surprising to you, I'd suggest&nbsp;the aforementioned name resolu=
tion page in the php manual. It's not exactly long, you can probably read=
 it quicker than this email.</div></blockquote><br><div>You say it's by d=
esign, I say it's a bad design and should be fixed.</div>
--66c8d6f3_19495cff_15341--