> On 24 Aug 2024, at 01:37, John Coggeshall <j...@coggeshall.org> wrote: > > > > 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. >
If you're going to make a claim, but then refuse to back it up with any kind of evidence when challenged, myself and most others are going to ignore your claim, FYI. > 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. > How do you have a deprecation notice for a *new* function before it exists? If you took this approach, any new global functions would have to have an RFC and then wait until the next major version to actually be implemented - so for example, str_contains, str_starts_with and str_ends_with were all added in PHP8.0, back in 2020 - four years ago. But because the RFC's were all conducted after the release of 7.4 (the last 7.x release), none of those functions would be eligible to introduce into the language yet, because a deprecation notice introduced with 8.0 won't enforce it's warned change until 9.0, which we don't even have a date for yet. Taking this approach, the following functions would currently still be waiting in limbo for 9.0 to arrive and become available: str_contains str_starts_with str_ends_with get_debug_type fdiv array_is_list memory_reset_peak_usage ini_parse_quantity str_increment str_decrement stream_context_set_options And that's just considering the "standard" or "core" functions - if you include extensions that are considered "core" there's a heap more. > > 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. That flies in the face of relatively common logic taken on most RFCs these days, where potential impact on future features is a deliberate consideration, so as *not* to negatively impact them, rather than an attempt to "get in first" regardless of negative consequences down the line. > > > 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 Are you referring to the `[$a, $b] = $array;` syntactic sugar? You can't implement that in userland, and it didn't introduce any BC breaks, so I don't see how it's relevant? array_column is considered to be pretty common functionality, and the C version is about 5x faster than the equivalent userland implementation (comparing against the polypill the author of array_column provided) under php8.3, and was about 6x faster under php5.5 when it was introduced. > > 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. Can you give an example of any other language where global symbols take precedence over locally defined symbols of the same name?
