On Aug 23 2024, at 1:46 pm, Stephen Reay <[email protected]> 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.