On 20. May 2019, at 20:42, Theodore Brown <theodor...@outlook.com> wrote: > > Can you clarify? I'm not sure what performance improvement trick you > are referring to, or what you mean by "importing all functions". Are > you saying it's a misconception that triggering an autoloader on > unqualified function calls in a namespace will slow down performance? > As I understand it, this is the roadblock for function autoloading. > > Best regards, > Theodore
Yes, this is misconception. Namespace resolutions are cached. First fixer tool bringing support for this was correct: PHP-CS-Fixer auto imports only optimized functions for this very same reason. > On 20. May 2019, at 20:45, Marco Pivetta <ocram...@gmail.com> wrote: > > Disabling function mocking is good ©️ > > It was a terrible practice in first place, and it is usually done for > impure functions that should be wrapped in integration-tested adapters. …which dramatically affects design of code. Nobody builds injectable replacements for these calls. As always, you are speaking from POV of library maintainer. As a user of your library, you don’t have perfect design. Nobody has. As a user of the library, I want to have ability to replace every aspect of it without copying it, while preserving simplicity - this is impossible to do, because these goals are in opposition. As a contributor of the library, I have found it impossible to write tests for some parts of very same library, because its code style guide dictates importing all the functions which makes it impossible to mock function call. And replacing them with injectable adapters was deemed overkill (and is subject of BC concerns). Anyways, it doesn’t matter. Disabling function fallback for all functions has very little benefit like I mentioned. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
