> On 23 Aug 2024, at 23:56, John Coggeshall <[email protected]> wrote:
>
>
>
> On Aug 23 2024, at 12:27 pm, Stephen Reay <[email protected]> wrote:
>
> The current inconsistencies between symbol types can be avoided in userland in a 100%
> consistent way. Import or qualify the symbols you use, all the time, and you have 0 inconsistencies
> or bizarreness in terms of what it used when.
>
>
> So are you essentially arguing that we should put the burden on the majority of users, most of
> whom (documented by us or not) likely will have no idea what the problem is or potential
> consequences are?
No, I'm saying that the "problem" of performance has had a pretty simple, consistent
solution since namespaces were added to the language, and that for the vast, vast majority of
projects it's a stretch to even classify it as a problem.
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.
> 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 think you are exaggerating the impact of the BC break here. In fact Ilija measured the impact
> on the top 1000 composer packages:
>
> https://gist.github.com/iluuu1994/4b83481baac563f8f0d3204c697c5551
Great, so 0.24% of public packages represented, and 0% of private code represented. That certainly
seems representative.
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.
>
> I was specifically pointing out that a small number of people complaining about this is a
> ridiculous reason to even consider the change.
>
> That's one take. Another take is this is an easy win for a few percentage points bump in
> speed, with improved supply-chain security for composer packages that has a minimal impact on users.
>
I was clarifying (to someone else) that the claim about who objects or doesn't, was never mine.
It's a bit weird that in one email you admit you have no data, and in the next claim
"minimal impact on users". Either you have data or you don't.
> Great, how about the solution that doesn't have any BC, and works in every version back to
> 5.3?
>
> By this logic, we should never introduce BC breaks.
We should aim to reduce BC breaks as much as possible, and especially BC breaks that have an ongoing
impact over time (i.e. new breaks into the future). The point is that every single *technical*
problem pointed out in the original issue, and the email that arose from it, can be solved, and
could be soled 15 years ago, by using a \ for global functions (or using a
use statement), exactly the same way you do with global classes and interfaces.
>
> Great, so then we can resolve this whole thing by adding a footnote to the "Name
> resolution rules" page in the manual that (a) recommends using qualified names (i.e. prefix
> with a \) and (b) provides deeper details of the reasons for those who care.
>
> From the perspective of program language _design_ (which is what we're talking about
> here), the goal is to create a language that helps the developer do something faster/better/easier,
> not do the wrong thing (slower code, etc.) by default and dump the responsibly for that on
> developers by expecting them to read a footnote buried in a doc. Especially when the justification
> is because there's concerns that code written in 2009 won't work anymore.
>
To be clear, we aren't "creating" a language. We're talking about a hypothetical
*change* to a core aspect of an existing language, that is used by literally millions of developers
around the planet.
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.
> I mean this:
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.
As I and others have said: if your project has a credible security risk because of this
functionality, you have bigger problems than needing to use a leading backslash.
> At it's core a vast majority of the functionality of the PHP language exists within
> internally-implemented functions, not classes.
There's a lot of procedural APIs in the standard library/extensions, sure. But people still
*use* classes *a lot* though, and there is in general a push towards more OOP API's and less
groups of functions - particularly for anything with state (e.g. see recent discussions and
RFC's about Curl objects, HTTP Request data objects, BCMath Number object, Tokenizer, etc).
> So yes, I think it's entirely reasonable that people would expect that internal functions
> resolve at a higher priority than user-defined functions with the same name
OK, you can think that. I don't agree. One of the top, if not the top thing people complain
about PHP is inconsistencies in the standard library - the order of needle/haystack arguments being
different in string vs array functions is probably one of the most well known.