On Fri, 23 Aug 2024, 11:02 Stephen Reay, <php-li...@koalephant.com> wrote:
> > > > On 23 Aug 2024, at 15:29, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> > wrote: > > > > having global as the default mode (even if we provide an option for > local) is much less disruptive to existing code. > > Hi Rowan, > > I don't disagree with this summary of the current state, but I think this > misses an important factor: namespaced functions are currently nowhere near > as popular as namespaced classes, and a significant part of that is almost > certainly because we don't have function autoloading, nor any kind of > visibility controls for functions (eg package private). > > Making relative function names do the opposite of relative class names > sounds like a great way to permanently kill any prospects of encouraging > developers to use regular namespaced functions in place of static classes > as "bag of functions", which is what we keep hearing we should use - most > notably on a recent RFC to embody the concept of a static class. > > So we're told "no don't use classes for static functions like that, use > proper functions". > > We already can't autoload them which makes them less appealing, and less > practical. > > In a world where global functions take precedence over local ones because > some people don't like writing a single \ character, autoloading would be a > moot point because if you preference global functions you're implicitly > telling developers they shouldn't write namespaced functions, by making > them harder and less intuitive to use. > > > Cheers > > Stephen I've taken the time to carefully read Ilija's proposal and all followup messages. This is a great proposal, Ilija, it will immediately benefit 95%+ userbase. It looks to me that the pro's outweigh the con's, as well as Ilija having done good research here already. As for next steps, I'm suggesting that Ilija reach out to the core team at Symfony, Zend, Laravel as well as WordPress, Magento, Drupal teams .. for their consideration and input, and bring it back here/RFC. The latter group of project's codebases can be quite "quirky", and quite creative, in how they use PHP compared to a traditional "framework". We need to understand how this could negatively impact how their systems are put together, and we definitely want to, upfront, identify anything we wouldn't normally think of, that they can spot, since they know their own codebases better than we do. We already have the composer analysis, so after we have these framework/project analysis then we can make a strongly informed decision on the impact, positively or negatively, this change will make. Many thanks, Paul
