2016-08-08 19:06 GMT+02:00 Rasmus Schultz <ras...@mindplay.dk>: > > If not, I don't see why we ever need to be able to autoload global > functions > > Well, for consistency. >
Not only for consistency, but also for things like polyfills, e.g. random_compat. Regards, Niklas > For one, if you're refactoring a global function to a namespaced one, this > inconsistency is going to be surprising. > > In general, any inconsistency in a language is surprising. Why only > non-global functions can autoload, is going to require a longer > explanation. And that's bad. > > If we support auto-loading only for namespaced functions, we're actively > favoring (potentially micro-) performance over consistency. > > I use global functions. I know that's not popular, but it's a language > feature, and I use it - for things like test-frameworks and global view > helper-functions. > > Single namespace spanning multiple files is also a case for me - that's not > a decision we should make; likely, a PSR and Composer auto-loading features > will drive those decisions. One should have the freedom to add a new > function to an existing namespace, and make that function auto-load, while > packaging that function as a separate optionally-installable package. > > I can't see the introduction of arbitrary restrictions or limitations > leading to anything good, language-wise. > > Unless there's a demonstrated, critical performance issue with auto-loading > of global functions, please, let's not cripple this feature with > inconsistencies from the get-go! > > > On Mon, Aug 8, 2016 at 6:46 PM, Rowan Collins <rowan.coll...@gmail.com> > wrote: > > > On 08/08/2016 17:00, Levi Morrison wrote: > > > >> I think saying "add a backslash in front of your function names to > >> avoid them being slow" will just lead to lots of "lol wtf php sux". > >> > >> > >> They'll say the same when function and class autoloading don't work the > >> same way anyway. I think unifying their behavior over time is the best > >> solution forward. Yes, I'm talking about a BC break eventually, but the > >> suggestion to autoload only fully qualified function names could buy us > >> the time to make that BC break less severe. > >> > > > > > > Do you mean eventually changing the name resolution rules for functions > to > > match those for classes? I wasn't around at the time it was discussed, > and > > if we were adding them now would be tempted to say the leading \ should > > always be mandatory, just like it is for classes. But since we have what > we > > have, I don't see that big an advantage to changing it. > > > > If not, I don't see why we ever need to be able to autoload global > > functions. "You want autoloading? Put it in a namespace." Like I say, > that > > leaves the very small edge case of a single namespace spanning multiple > > files, and an autoloader implementation able to include one of them when > a > > function is called from another. > > > > > > Regards, > > -- > > Rowan Collins > > [IMSoP] > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
