> On 23 Aug 2024, at 23:56, John Coggeshall <j...@coggeshall.org> wrote: > > > > On Aug 23 2024, at 12:27 pm, Stephen Reay <php-li...@koalephant.com> 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.
