On Aug 23 2024, at 1:46 pm, Stephen Reay <php-li...@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.
