> On 24 Aug 2024, at 01:37, John Coggeshall <[email protected]> wrote:
>
>
>
> 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.
>
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?