# [DRAFT] [RFC] Function autoloading - Thread: https://externals.io/message/68693 - Original archive: https://news-web.php.net/php.internals/68693 - Started by Anthony Ferrara on 2013-08-30T01:23:08+00:00 - Messages: 71 - RFC: Function Autoloading (mark 5) (Declined) — https://externals.io/rfc/function-autoloading-five-oh.md - RFC: Function Autoloading (Withdrawn) — https://externals.io/rfc/function_autoloading.md - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/68693.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #68693 — Anthony Ferrara — 2013-08-30T01:23:08+00:00 URL: https://externals.io/message/68693#68693 All, I have created a new draft RFC implementing function and constant autoloading in master: https://wiki.php.net/rfc/function_autoloading All feedback is welcome. Thanks Anthony --- ## #68695 — Stas Malyshev — 2013-08-30T04:57:14+00:00 URL: https://externals.io/message/68693#68695 · In reply to: #68693 Hi! > I have created a new draft RFC implementing function and constant > autoloading in master: > > https://wiki.php.net/rfc/function_autoloading > > All feedback is welcome. I think it is an unnecessary complication. Classes fit autoloader paradigm nicely, since the usual pattern is one class per one file (actually recommended in PSR), so it is easy to establish one-to-one automatic mapping between classes and files (also recommended in the PSR). But for functions nobody does this. This means that to implement function autoloader one will need to have a complicated and fragile logic (since there's no way to ensure this logic would be in sync with actual content of files containing multiple functions). Moreover, since this replaces a simple hash lookup with additional two function calls (and also other operations included in those) everywhere in the engine, it will also have performance impact of one of the most frequently used operations in the engine - function calls - while providing absolutely no benefit for 100% of existing code and 99.99% of future code. Putting autoloading of different entities into one function makes very little sense to me - why would the same code load both classes and functions? How would it do that besides ugly switch that just stuffs two completely different logic pieces into one function for no reason? The example given in the RFC is certainly not what anybody would actually want their autoloaders to do, so I fail to see any case for doing it and for putting loading more than one entity into one function (that given that autoloading function would be desirable at all, which it still doesn't seem so for me). It is -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #68696 — Stas Malyshev — 2013-08-30T04:58:43+00:00 URL: https://externals.io/message/68693#68696 · In reply to: #68695 Hi! > It is Oops, clicked too soon. I wanted to conclude that I think it is too many complications in the engine for too little gain. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #68697 — Laruence — 2013-08-30T05:36:27+00:00 URL: https://externals.io/message/68693#68697 · In reply to: #68696 > Hi! > > > […] > > Oops, clicked too soon. I wanted to conclude that I think it is too many > complications in the engine for too little gain. I agree with Stas here. thanks > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #68698 — Sara Golemon — 2013-08-30T06:51:34+00:00 URL: https://externals.io/message/68693#68698 · In reply to: #68695 > I think it is an unnecessary complication. Classes fit autoloader > paradigm nicely, since the usual pattern is one class per one file > (actually recommended in PSR), so it is easy to establish one-to-one > automatic mapping between classes and files (also recommended in the > PSR). But for functions nobody does this. This means that to implement > function autoloader one will need to have a complicated and fragile > logic (since there's no way to ensure this logic would be in sync with > actual content of files containing multiple functions). > > I disagree on the basis that namespaced functions/constants *do* fit the same autoloading paradigm. Moreover, since this replaces a simple hash lookup with additional two > function calls (and also other operations included in those) everywhere > in the engine, it will also have performance impact of one of the most > frequently used operations in the engine - function calls - while > providing absolutely no benefit for 100% of existing code and 99.99% of > future code. > > Those function calls would only kick in if the function/constant wasn't already defined, which will be the exception case, so perf isn't a strong argument. > Putting autoloading of different entities into one function makes very > little sense to me - why would the same code load both classes and > functions? How would it do that besides ugly switch that just stuffs two > completely different logic pieces into one function for no reason? The > example given in the RFC is certainly not what anybody would actually > want their autoloaders to do, so I fail to see any case for doing it and > for putting loading more than one entity into one function (that given > that autoloading function would be desirable at all, which it still > doesn't seem so for me). > > That I agree with 100%. -Sara --- ## #68699 — Stas Malyshev — 2013-08-30T07:02:18+00:00 URL: https://externals.io/message/68693#68699 · In reply to: #68698 Hi! > I disagree on the basis that namespaced functions/constants *do* fit the > same autoloading paradigm. If they're already namespaced, what prevents one to put it in a class and use good old PSR-compatible loading? > Those function calls would only kick in if the function/constant wasn't > already defined, which will be the exception case, so perf isn't a > strong argument. Not according to the code I see in the patch. There I see 2 func calls (among other things) before the hash is even looked up. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #68700 — Sara Golemon — 2013-08-30T07:08:50+00:00 URL: https://externals.io/message/68693#68700 · In reply to: #68699 > If they're already namespaced, what prevents one to put it in a class > and use good old PSR-compatible loading? > > Nothing, really... Just countering your specific premise. > > […] > > Not according to the code I see in the patch. There I see 2 func calls > (among other things) before the hash is even looked up. > > Well, the patch needs work obviously. I'm living in a magical world where that's already been fixed. :) -Sara --- ## #68701 — Sebastian Krebs — 2013-08-30T07:21:45+00:00 URL: https://externals.io/message/68693#68701 · In reply to: #68699 2013/8/30 Stas Malyshev > Hi! > > > […] > > If they're already namespaced, what prevents one to put it in a class > and use good old PSR-compatible loading? > Well, static methods aren't the same as functions. > > > […] > > Not according to the code I see in the patch. There I see 2 func calls > (among other things) before the hash is even looked up. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > -- github.com/KingCrunch --- ## #68702 — Sebastian Krebs — 2013-08-30T07:29:55+00:00 URL: https://externals.io/message/68693#68702 · In reply to: #68695 2013/8/30 Stas Malyshev > Hi! > > > […] > > I think it is an unnecessary complication. Classes fit autoloader > paradigm nicely, since the usual pattern is one class per one file > (actually recommended in PSR), so it is easy to establish one-to-one > automatic mapping between classes and files (also recommended in the > PSR). Autoloading was introduced long before PSR-0 and PSR-0 is also only a recommendation. So saying "class autoloading was easily introduceable, because there was _always_ a class<->file mapping" is somehow misleading. > But for functions nobody does this. This means that to implement > function autoloader one will need to have a complicated and fragile > logic (since there's no way to ensure this logic would be in sync with > actual content of files containing multiple functions). > This is the same complicated and fragile logik you need for class loading. For example compared to PSR-0 functions could be implemented in a file named after the namespace. An autoloader would be very similar to every already existing PSR-0 class loader. > > Moreover, since this replaces a simple hash lookup with additional two > function calls (and also other operations included in those) everywhere > in the engine, it will also have performance impact of one of the most > frequently used operations in the engine - function calls - while > providing absolutely no benefit for 100% of existing code and 99.99% of > future code. > > Putting autoloading of different entities into one function makes very > little sense to me - why would the same code load both classes and > functions? How would it do that besides ugly switch that just stuffs two > completely different logic pieces into one function for no reason? The > example given in the RFC is certainly not what anybody would actually > want their autoloaders to do, so I fail to see any case for doing it and > for putting loading more than one entity into one function (that given > that autoloading function would be desirable at all, which it still > doesn't seem so for me). > It is > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > -- github.com/KingCrunch --- ## #68703 — Sebastian Bergmann — 2013-08-30T07:35:38+00:00 URL: https://externals.io/message/68693#68703 · In reply to: #68693 Am 30.08.2013 03:23, schrieb Anthony Ferrara: > All feedback is welcome. Can we please get rid off the __autoload() function first before we consider adding new functionality? -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #68704 — Julien Pauli — 2013-08-30T08:42:57+00:00 URL: https://externals.io/message/68693#68704 · In reply to: #68703 On Fri, Aug 30, 2013 at 9:35 AM, Sebastian Bergmann wrote: > Am 30.08.2013 03:23, schrieb Anthony Ferrara: > > […] > > Can we please get rid off the __autoload() function first before we > consider adding new functionality? > Huge +1 to start deprecating this feature, then completely remove it. And to continue the discussion, I recall that we, as PHP contributors, disagreed to include a PSR-0 compatible autoloader into Core. So the argument of PSR-0 is not valid for me, as it has nothing to do with PHP internals and actually is "just a recommandation" we didn't want to merge into PHP. Perhaps is it also time to talk about this subject back and finally all agree on a default recommanded implentation of autoloading in PHP (internally supported) ? Julien.Pauli --- ## #68706 — Julien Pauli — 2013-08-30T08:49:35+00:00 URL: https://externals.io/message/68693#68706 · In reply to: #68693 On Fri, Aug 30, 2013 at 3:23 AM, Anthony Ferrara wrote: > All, > > I have created a new draft RFC implementing function and constant > autoloading in master: > > https://wiki.php.net/rfc/function_autoloading > > All feedback is welcome. > Just to say : one benefit of this work would be to finally have autoload functionnality (which is a Core feature IMO) included in Zend/ and no more in an extension. Julien.Pauli --- ## #68705 — Sebastian Bergmann — 2013-08-30T08:49:50+00:00 URL: https://externals.io/message/68693#68705 · In reply to: #68704 Am 30.08.2013 10:42, schrieb Julien Pauli: > Perhaps is it also time to talk about this subject back and finally all > agree on a default recommanded implentation of autoloading in PHP > (internally supported) ? The only autoloader implementation that makes sense to me is to use a tool such as https://github.com/theseer/Autoload to generate the code. That being said, I do not thinkthat the PHP project should recommend a specific tool but rather the concept. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #68711 — Nikita Popov — 2013-08-30T09:42:40+00:00 URL: https://externals.io/message/68693#68711 · In reply to: #68695 On Fri, Aug 30, 2013 at 6:57 AM, Stas Malyshev wrote: > I think it is an unnecessary complication. Classes fit autoloader > paradigm nicely, since the usual pattern is one class per one file > (actually recommended in PSR), so it is easy to establish one-to-one > automatic mapping between classes and files (also recommended in the > PSR). But for functions nobody does this. This means that to implement > function autoloader one will need to have a complicated and fragile > logic (since there's no way to ensure this logic would be in sync with > actual content of files containing multiple functions). > For functions people do not commonly use a one-to-one mapping between a function name and a file, that's true. But there commonly *is* a one-to-one mapping between a *namespace* and a file. So if you have a function foo\bar\baz it will be in the file foo/bar.php (which defines all functions of namespace foo\bar). I think this is a rather common pattern in functional (or function-heavy) libraries and I use this myself too. Apart from such a namespace-to-file mapping you can also use the same approach some people use for classes: Just pregenerate the name-to-file mappings in an array, then loop up from there (e.g. theseer/autoload). This is one of the rare autoloading concepts that actually properly works in PHP (much unlike PSR-0, which fails to honor case-insensitivity). > Moreover, since this replaces a simple hash lookup with additional two > function calls (and also other operations included in those) everywhere > in the engine, it will also have performance impact of one of the most > frequently used operations in the engine - function calls - while > providing absolutely no benefit for 100% of existing code and 99.99% of > future code. > I'd assume that this isn't yet the final patch and it will be improved to make sure that there is no significant performance regression for function calls not making use of autoloading. This should just be a matter of inlining the part of the function with the direct hash lookup and avoiding a duplicate lcname call. (Maybe in the engine just keep the old if (zend_hash_find(...)) and add an else { autoload(); }.) Putting autoloading of different entities into one function makes very > little sense to me - why would the same code load both classes and > functions? I don't think it makes much sense to use the same function to autoload classes and functions, but I think it makes sense to autoload both functions and constants with the same mechanism, because presumably both would follow the same naming-convention (e.g. the namespace-to-file mapping mentioned above). So I think this is a useful feature and I definitely don't see a reason why we need to explicitly prevent it. Anyway, I'm +1 on this :) PHP has been neglecting it's functional sides. The "use function" RFC and this one work on improving this a bit. Nikita --- ## #68713 — johannes@schlueters.de — 2013-08-30T09:46:48+00:00 URL: https://externals.io/message/68693#68713 · In reply to: #68706 > Just to say : one benefit of this work would be to finally have autoload > functionnality (which is a Core feature IMO) included in Zend/ and no more > in an extension. What is the benefit, except having more stuff in the engine? SPL is part of the core. Let's not pack the engine with stuff not needed there. johannes --- ## #68714 — Pierre Joye — 2013-08-30T10:40:10+00:00 URL: https://externals.io/message/68693#68714 · In reply to: #68713 On Fri, Aug 30, 2013 at 11:46 AM, Johannes Schlüter wrote: > > > […] > > What is the benefit, except having more stuff in the engine? SPL is part > of the core. Let's not pack the engine with stuff not needed there. Can we stop this madness of considering SPL as non standard or as a 'let put everything we don't know in there' extension? It was created to provided some standard advanced functions or structures. SPL was then used to work around some of the limitation of the engine, or add features not desired by some of the core devs, because no compromise was found. This must end, either it is needed and should be in the engine, or it is not and can go in pecl. SPL is standard, and always enabled. It should not continue to become a 2nd layer to the engine but to provide advanced features like what it initially did. -- Pierre @pierrejoye | http://www.libgd.org --- ## #68717 — Anthony Ferrara — 2013-08-30T11:16:59+00:00 URL: https://externals.io/message/68693#68717 · In reply to: #68695 Stas, Moreover, since this replaces a simple hash lookup with additional two > function calls (and also other operations included in those) everywhere > in the engine, it will also have performance impact of one of the most > frequently used operations in the engine - function calls - while > providing absolutely no benefit for 100% of existing code and 99.99% of > future code. > This was already directly covered in the RFC already: https://wiki.php.net/rfc/function_autoloading#c_api_backwards_compatibility Basically, two new macros are introduced which expand directly to hash lookups. #define ZEND_LOOKUP_FUNCTION_BY_NAME(name, name_length, fbc) (zend_hash_find(EG(function_table), (name), (name_length) + 1, (void**) (fbc)) == SUCCESS || zend_lookup_function((name), (name_length), (fbc)) == SUCCESS) So nothing changes from present (at all) unless a function is not defined. Today, that's an error case. So the only performance change occurs if zend_hash_find (which is already there) returns FAILURE. THEN the logic which includes autoloading would run. So no, there should be no performance impact at all to existing code thanks to operator short circuiting. Anthony --- ## #68718 — Anthony Ferrara — 2013-08-30T11:28:07+00:00 URL: https://externals.io/message/68693#68718 · In reply to: #68695 Stas, On Fri, Aug 30, 2013 at 12:57 AM, Stas Malyshev wrote: > Hi! > > > […] > > I think it is an unnecessary complication. Classes fit autoloader > paradigm nicely, since the usual pattern is one class per one file > (actually recommended in PSR), so it is easy to establish one-to-one > automatic mapping between classes and files (also recommended in the > PSR). But for functions nobody does this. This means that to implement > function autoloader one will need to have a complicated and fragile > logic (since there's no way to ensure this logic would be in sync with > actual content of files containing multiple functions). I don't think that's a fair argument. It's a bit "We don't support function autoloading, so function autoloading doesn't make sense". As far as complicated and fragile logic, as Nikita pointed out, you could put all of your functions inside of a "functions,php" in a particular namespace. Then, with use function, you can capture the missing function call, and cut off the function name, require_once /path/to/namespace/functions.php, and be good. Or, alternatively, you can keep a mapping of function->filename. There's no need or requirement for one-class, one-function or one-constant. Furthermore, I think that's up to the community to decide how to do. They mostly settled on a 1-class-to-1-file rule (which was not the case prior to __autoload/spl_autoload). I am fully confident that they will find a way that makes sense, if given the ability. > Putting autoloading of different entities into one function makes very > little sense to me - why would the same code load both classes and > functions? How would it do that besides ugly switch that just stuffs two > completely different logic pieces into one function for no reason? The > example given in the RFC is certainly not what anybody would actually > want their autoloaders to do, so I fail to see any case for doing it and > for putting loading more than one entity into one function (that given > that autoloading function would be desirable at all, which it still > doesn't seem so for me). > That's why this is a RFC which is up for discussion. That's why this is a draft instead of a proposal. Would you rather see: bool php\autoload_class_register($callback, $prepend)) bool php\autoload_function_register($callback, $prepend) bool php\autoload_constant_register($callback, $prepend) Would you rather having the single autoload regstier, but enforcing that type must be a single type? Would you rather see interfaces? interface php\Autoloader {} interface php\AutoloaderClass extends php\Autoloader { public function loadClass($name); } interface php\AutoloaderFunction extends php\Autoloader { public function loadFunction($name); } interface php\AutoloaderConstant extends php\Autoloader { public function loadConstant($name); } bool php\autoload_register(php\Autoloader $loader, $prepend); The syntax provided in this RFC is a proposal. It's not set in stone. If you don't like it, let's work towards a better one! Thanks, Anthony --- ## #68719 — Anthony Ferrara — 2013-08-30T12:31:00+00:00 URL: https://externals.io/message/68693#68719 · In reply to: #68693 All, I have updated the RFC to include 2 new benchmarks. For normal class loading, this proposal shows at worst no change to loading time. At best, it may actually improve it because at least one zend_function_call is avoided (to spl_autoload_call). For constants and function calls, the benchmark shows that the difference is well within the margin of error for the test (considering variances of 5% to 10% were common in my running of the tests). So hopefully this will dispel any worry about performance regressions in currently defined cases. The times where performance will take a hit, is with undefined functions and constants. Today, an undefined function will fatal error, so this performance hit would be 0, as it would enable something that's not possible today. The only regression can be where autoloaders are defined, and people are relying on the legacy undefined constant behavior (which triggers an E_NOTICE). Anthony On Thu, Aug 29, 2013 at 9:23 PM, Anthony Ferrara wrote: > All, > > I have created a new draft RFC implementing function and constant > autoloading in master: > > https://wiki.php.net/rfc/function_autoloading > > All feedback is welcome. > > Thanks > > Anthony --- ## #68720 — Nicolas Grekas — 2013-08-30T12:53:41+00:00 URL: https://externals.io/message/68693#68720 · In reply to: #68719 Hi The only regression can be where autoloaders are defined, and people are > relying on the legacy undefined constant behavior (which triggers an > E_NOTICE). > that makes me think about this code : What autoload should be triggered? "foo\bar" or "bar"? Both are valid isn't it? Should autoloading functions and constants be restricted to namespaced ones only? Then the BC issue you spot would disappear. --- ## #68721 — Bryan C. Geraghty — 2013-08-30T13:13:07+00:00 URL: https://externals.io/message/68693#68721 · In reply to: #68706 The problem I see with implementing this kind of functionality in Core is that it relies heavily on convention; PSR-0 is specifically a configuration of the core autoloader which allows any configuration, as it should. And while most of the community has adopted PSR-0 (as have I), I do not think Core is the place for it. Bryan -----Original Message----- From: julienpauli@gmail.com [mailto:julienpauli@gmail.com] On Behalf Of Julien Pauli Sent: Friday, August 30, 2013 3:50 AM To: Anthony Ferrara Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading Just to say : one benefit of this work would be to finally have autoload functionnality (which is a Core feature IMO) included in Zend/ and no more in an extension. Julien.Pauli --- ## #68722 — Bryan C. Geraghty — 2013-08-30T13:30:04+00:00 URL: https://externals.io/message/68693#68722 · In reply to: #68706 Having said that, I think the overall concept of function autoloading is a useful feature and haven't seen a good argument for why it shouldn't be supported. Bryan -----Original Message----- From: Bryan C. Geraghty [mailto:bryan@ravensight.org] Sent: Friday, August 30, 2013 8:13 AM To: 'Julien Pauli' Cc: 'internals@lists.php.net' Subject: RE: [PHP-DEV] [DRAFT] [RFC] Function autoloading The problem I see with implementing this kind of functionality in Core is that it relies heavily on convention; PSR-0 is specifically a configuration of the core autoloader which allows any configuration, as it should. And while most of the community has adopted PSR-0 (as have I), I do not think Core is the place for it. Bryan -----Original Message----- From: julienpauli@gmail.com [mailto:julienpauli@gmail.com] On Behalf Of Julien Pauli Sent: Friday, August 30, 2013 3:50 AM To: Anthony Ferrara Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading Just to say : one benefit of this work would be to finally have autoload functionnality (which is a Core feature IMO) included in Zend/ and no more in an extension. Julien.Pauli --- ## #68729 — Leigh — 2013-08-30T16:13:05+00:00 URL: https://externals.io/message/68693#68729 · In reply to: #68719 > For constants and function calls, the benchmark shows that the difference > is well within the margin of error for the test (considering variances of > 5% to 10% were common in my running of the tests). > > So hopefully this will dispel any worry about performance regressions in > currently defined cases. > > The times where performance will take a hit, is with undefined functions > and constants. Today, an undefined function will fatal error, so this > performance hit would be 0, as it would enable something that's not > possible today. I would assume there is actually potential for performance gain for functions being autoloaded in larger codebases when the *_once calls are removed that would normally load the common functions files. --- ## #68735 — Laruence — 2013-08-30T17:04:32+00:00 URL: https://externals.io/message/68693#68735 · In reply to: #68729 > > > […] > > I would assume there is actually potential for performance gain for > functions being autoloaded in larger codebases when the *_once calls are > removed that would normally load the common functions files. I just reply to this point: No. thinking we already have opcache there. so, *compiling* Functions is cheap. but if with function autoloading, *function autoloading* will execute every run. thanks -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #68737 — Stas Malyshev — 2013-08-30T17:09:31+00:00 URL: https://externals.io/message/68693#68737 · In reply to: #68704 Hi! > And to continue the discussion, I recall that we, as PHP contributors, > disagreed to include a PSR-0 compatible autoloader into Core. This has nothing to do with PSR-0 in core. This has everything to do with the fact that class-per-file is an accepted pattern in PHP and many other languages, and considered by many to be the best practice. However, nobody uses function-per-file. > Perhaps is it also time to talk about this subject back and finally all > agree on a default recommanded implentation of autoloading in PHP > (internally supported) ? Again, it does not matter *how* classes are matched to files and where the slashes are put in. What matters is that classes and files are roughly in one-to-one correspondence (there are exceptions, but there are just that - exceptions - and usually for classes that aren't part of public API). So I'd like not to sidetrack the discussion into discussing which way of putting slashes in is the best and whether PHP core should have backslash-to-forward-slash function. It is not what it is about. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- Next page: https://externals.io/message/68693.md?page=2