On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz <ras...@mindplay.dk> wrote:
> I'd really like to see the function auto-loading proposal revived and/or > possibly simplified. > > The fact that functions are hard (in some cases impossible) to reach by > manually issuing require/include statements is, in my opinion, half the > difficulty, and a much more deeply rooted language problem exacerbating > what should be trivial problems - e.g. install a Composer package, import > (use) and call the functions. > > Looks like a fair amount of work and discussion was done in 2013 on this > RFC: > > https://wiki.php.net/rfc/function_autoloading > > There was a (now stale) proof of concept implementation for the parent RFC > as well: > > https://wiki.php.net/rfc/function_autoloading2 > > What happened? > > It looks like the discussion stalled mostly over some concerns, including > reservations about performance, which were already disproved? > > One issue apparently was left unaddressed, that of whether a call to an > undefined function should generate an auto-load call to a namespaced or > global function - I think this would not be difficult to address: trigger > auto-loading of the namespaced function first, check if it was loaded, and > if not, trigger auto-loading of the global function. I feel like the problem here did not get across properly. Calling the autoloader if a global function with the name exists will totally kill performance. This means that every call to strpos() or any of the other functions in the PHP standard library will have to go through the autoloader first, unless people use fully qualified names (which, currently, they don't). This is completely out of the question. (The case where neither the namespaced nor the global function exists is not the problem. In that case calling the autoloader for the namespaced and non-namespaced names in sequence is of course unproblematic.) Nikita > Most likely a PSR > along with Composer auto-loading features will favor a best practice of > shipping packages with namespaced functions only, so the performance > implications of checking twice would be negligible in practice. > > Being basically unable to ship or consume purely functional packages leaves > the functional side of the language largely an unused historical artifact, > which is sad. Keeping things functional and stateless often lead to more > predictable and obvious code - I think the absence of good support for > functions encourages a lot of over-engineering, e.g. developers > automatically making everything a class, not as a design choice, for the > sole reason of being able to ship and reuse what should be simple > functions. > > This RFC looks pretty solid to me. > > What will it take to get this rolling again? >
