# [RFC] Function autoloading through spl_autoload* - Thread: https://externals.io/message/54425 - Original archive: https://news-web.php.net/php.internals/54425 - Started by Ferenc Kovacs on 2011-08-06T11:15:29+00:00 - Messages: 39 - RFC: Function autoloading through spl_autoload* (Inactive) — https://externals.io/rfc/autofunc.md - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/54425.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 --- ## #54425 — Ferenc Kovacs — 2011-08-06T11:15:29+00:00 URL: https://externals.io/message/54425#54425 Hi. I would like to introduce this RFC which would provide function autoloading through the spl_autoload facility without userland BC breakage. https://wiki.php.net/rfc/autofunc -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54427 — Ryan McCue — 2011-08-06T12:24:21+00:00 URL: https://externals.io/message/54425#54427 · In reply to: #54425 Ferenc Kovacs wrote: > I would like to introduce this RFC which would provide function > autoloading through the spl_autoload facility without userland BC > breakage. Shouldn't the default type be T_CLASS|T_INTERFACE? -- Ryan McCue Hi. > > I would like to introduce this RFC which would provide function > autoloading through the spl_autoload facility without userland BC > breakage. > > https://wiki.php.net/rfc/autofunc --- ## #54515 — Ferenc Kovacs — 2011-08-12T09:02:23+00:00 URL: https://externals.io/message/54425#54515 · In reply to: #54427 > Ferenc Kovacs wrote: > > […] > > Shouldn't the default type be T_CLASS|T_INTERFACE? > sorry for the late reply. judging from your reply and the conversion on irc with Etienne, I think that the usage of the token constants are ambiguous(we have different token constants for classes and interfaces as you mentioned for example). originally I chose this because this would be fully backward compatible, but now I think that we should add new constants. what do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54516 — Sebastian Krebs — 2011-08-12T10:12:07+00:00 URL: https://externals.io/message/54425#54516 · In reply to: #54515 Hi, 2011/8/12 Ferenc Kovacs > > > […] > > sorry for the late reply. > judging from your reply and the conversion on irc with Etienne, I > think that the usage of the token constants are ambiguous(we have > different token constants for classes and interfaces as you mentioned > for example). > originally I chose this because this would be fully backward > compatible, but now I think that we should add new constants. > what do you think? > From the users point of view I don't care. It's just another constant. Also constants like SPL_AUTOLOAD_CLASS SPL_AUTOLOAD_FUNCTION SPL_AUTOLOAD_CONSTANT seems to be more obvious, because it reflects, that it belongs to spl-autoload. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu --- ## #54518 — Ferenc Kovacs — 2011-08-12T10:31:17+00:00 URL: https://externals.io/message/54425#54518 · In reply to: #54516 On Fri, Aug 12, 2011 at 12:12 PM, Sebastian Krebs wrote: > Hi, > > 2011/8/12 Ferenc Kovacs > > > […] > > From the users point of view I don't care. It's just another constant. Also > constants like > > SPL_AUTOLOAD_CLASS > SPL_AUTOLOAD_FUNCTION > SPL_AUTOLOAD_CONSTANT > > seems to be more obvious, because it reflects, that it belongs to > spl-autoload. > imo from the users point of view your suggested constant names are much better, plus the T_* constants are provided by the tokenizer extension, which AFAK could be disabled compilation time, and by itself would be a bad idea to couple the two extension. so +1 for your suggestion, I will update the RFC, and check out how hard would be to create a patch. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54539 — Jan Dolecek — 2011-08-12T13:54:34+00:00 URL: https://externals.io/message/54425#54539 · In reply to: #54518 Someone said that it won't be that easy, because functions are searched within a namespace first and when they don't exist there, then are called from global namespace. Example: On Fri, Aug 12, 2011 at 12:12 PM, Sebastian Krebs > wrote: > > […] > > imo from the users point of view your suggested constant names are > much better, plus the T_* constants are provided by the tokenizer > extension, which AFAK could be disabled compilation time, and by > itself would be a bad idea to couple the two extension. > > so +1 for your suggestion, I will update the RFC, and check out how > hard would be to create a patch. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu --- ## #54575 — Sebastian Krebs — 2011-08-14T12:06:00+00:00 URL: https://externals.io/message/54425#54575 · In reply to: #54539 Am 12.08.2011 15:54, schrieb Jan Dolecek: > Someone said that it won't be that easy, because functions are > searched within a namespace first and when they don't exist there, > then are called from global namespace. > > Example: > namespace example; > echo substr('Test', 1, 1); > > When calling function substr, Zend engine first tries to find function > example\substr. If such function doesn't exist, it tries just substr > which is found and called. Thanks to this lookup, we don't need to > escape all function calls with backslash prefix. > > echo not_found(1); > When trying to autoload a function, which one should be auto loaded? > "example\not_found" or "not_found"? Whats about "both"? - Does \ exists? - Does \ exists? Till here everything is like usual - Try to load \. Does \ exists? - Try to load \. Does \ exists? I make two additional assumptions: 1. Like PSR-0 developers may get used to put their functions into namespaces, thus custom functions usually get loaded in the first "autoload-step" 2. I don't think anybody will use one-function-per-file, thus (lets say) every function from one namespace is loaded at once. > Similar situation is with constants, because of BC a non-existing > constant must result in string with the same value as constant's name. > var_dump(MY_CONSTANT); // string(11) "MY_CONSTANT" > > Some programmes rely on it (though it's not recommended) and calling > autoloader everytime would add significant load to such apps. In my opinion code, that _relies_ on this should be treated as "unstable" anyway. I don't think it's very useful to take care of bad habits and also I don't think it's useful to accept/decline features/enhancements, because there are convenience/fallback-features, that were _never_ recommended. Also it's even not a bc-break, because it works. And however: There is a very easy workaround: | define('MY_CONSTANT', 'MY_CONSTANT'); ;) > > > Jan Dolecek > juzna.cz@gmail.com > > > > > > […] --- ## #54577 — Ferenc Kovacs — 2011-08-14T12:59:44+00:00 URL: https://externals.io/message/54425#54577 · In reply to: #54539 > Someone said that it won't be that easy, because functions are > searched within a namespace first and when they don't exist there, > then are called from global namespace. > > Example: > namespace example; > echo substr('Test', 1, 1); > > When calling function substr, Zend engine first tries to find function > example\substr. If such function doesn't exist, it tries just substr > which is found and called. Thanks to this lookup, we don't need to > escape all function calls with backslash prefix. > > echo not_found(1); > When trying to autoload a function, which one should be auto loaded? > "example\not_found" or "not_found"? first example\not_found then \not_found if necessary. > > > > Similar situation is with constants, because of BC a non-existing > constant must result in string with the same value as constant's name. > var_dump(MY_CONSTANT); // string(11) "MY_CONSTANT" > > Some programmes rely on it (though it's not recommended) and calling > autoloader everytime would add significant load to such apps. > the autoloader shouldn't affect this, if no const is found, then the constname should be used. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54581 — Derick Rethans — 2011-08-14T13:55:43+00:00 URL: https://externals.io/message/54425#54581 · In reply to: #54425 > I would like to introduce this RFC which would provide function > autoloading through the spl_autoload facility without userland BC > breakage. > > https://wiki.php.net/rfc/autofunc I understand the proposal, but I don't see any compelling reasons in the RFC of why we actually need autoloading for functions? For classes it makes sense because there is almost always a class to file mapping. For functions (and constants) that is not the case, so I am wondering how useful this function autoloading actually is. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #54583 — Nikita Popov — 2011-08-14T14:02:35+00:00 URL: https://externals.io/message/54425#54583 · In reply to: #54581 > I understand the proposal, but I don't see any compelling reasons in the > RFC of why we actually need autoloading for functions? For classes it > makes sense because there is almost always a class to file mapping. For > functions (and constants) that is not the case, so I am wondering how > useful this function autoloading actually is. As Sebastian already mentioned, if all functions in a namespace are grouped into one file, it would be simple to load that file using such a concept. --- ## #54587 — Stas Malyshev — 2011-08-14T18:17:26+00:00 URL: https://externals.io/message/54425#54587 · In reply to: #54583 Hi! > As Sebastian already mentioned, if all functions in a namespace are > grouped into one file, it would be simple to load that file using such > a concept. Why wouldn't you just use a class? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54593 — Sebastian Krebs — 2011-08-14T20:39:32+00:00 URL: https://externals.io/message/54425#54593 · In reply to: #54587 Hi, Am 14.08.2011 20:17, schrieb Stas Malyshev: > Hi! > > > > […] > > Why wouldn't you just use a class? Counterquestion: Why shouldn't I use functions? They exists, they are official supported, they are neither marked as deprecated, nor ever discussed to get removed at all. It feels a little bit weird to me, that I need to explain, why one wants to use functions, that are part of the language since ever. And (on the other hand) static methods are imo just something different. Regards, Sebastian --- ## #54595 — Sebastian Krebs — 2011-08-14T20:47:53+00:00 URL: https://externals.io/message/54425#54595 · In reply to: #54581 Hi, Am 14.08.2011 15:55, schrieb Derick Rethans: > > > > […] > > I understand the proposal, but I don't see any compelling reasons in the > RFC of why we actually need autoloading for functions? For the same reasons, why class-autoloading is useful: Loading when needed and avoiding unnecessary repetitive include-statements. > For classes it > makes sense because there is almost always a class to file mapping. For > functions (and constants) that is not the case, so I am wondering how > useful this function autoloading actually is. Like classes there may be also a function-to-filename-mapping, especially now, since namespaces exists. It is very easy to extend the PSR-0 standard (lets say: PSR-0.1 ;)) so functions and constants are covered by it too: - Constants and functions are in a file named after the namespace myNamespace\foo\bar => MyNamespace/foo/bar.php When class-autoloading were introduced there were no ^real^ class-to-file-mapping too. You had to define it yourself the time, when you wrote your `__autoload()`-function. It's nearly the same with functions/constants now, except that we are away from a single function and that there are already ideas, that may cover such mappings already. Or in my words: I don't see _any_ reason, why function-/constant-autoloading does _not_ exists ;) > > cheers, > Derick > Regards, Sebastian --- ## #54597 — Stas Malyshev — 2011-08-14T21:06:41+00:00 URL: https://externals.io/message/54425#54597 · In reply to: #54593 Hi! > Counterquestion: Why shouldn't I use functions? They exists, they are Because if you want to use functions of similar nature organized in a package, that's what classes are used for. You want to do something that goes contrary to how language is designed and then you want language to change to fit your wrong usage. I don't see how it's good for the language. > discussed to get removed at all. It feels a little bit weird to me, that > I need to explain, why one wants to use functions, that are part of the Please don't distort my words - nobody asked you why you need to use functions in general. I asked why you don't use mechanisms for grouping functions that exist in the language and work just fine with existing semantics and instead want new semantics that has its own problems. > language since ever. And (on the other hand) static methods are imo just > something different. How different? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54599 — Sebastian Krebs — 2011-08-14T21:50:05+00:00 URL: https://externals.io/message/54425#54599 · In reply to: #54597 Hi, Am 14.08.2011 23:06, schrieb Stas Malyshev: > Hi! > > > > […] > > Because if you want to use functions of similar nature organized in a > package, that's what classes are used for. When I must use classes are for packaging functions (that aren't functions anymore, when I make methods out of them), what are namespaces for? I'm just curious ^^ > You want to do something that > goes contrary to how language is designed and then you want language to > change to fit your wrong usage. I don't see how it's good for the language. I just want to use functions. Whats wrong with that? Really: Thats all. > > […] > > Please don't distort my words - nobody asked you why you need to use > functions in general. I asked why you don't use mechanisms for grouping > functions that exist in the language and work just fine with existing > semantics and instead want new semantics that has its own problems. Its not (only) about grouping functions, its about using custom functions at all. Grouping things is always a good idea and with namespaces (not classes) it is already possible in a very clean and easy way. There is no need to misuse OOP for that. As far as I can see there is absolutely nothing new here. That functions/constants should be covered by autoloading is the only thing I would like to see in one future release. > > […] > > How different? Static methods are (static) methods and functions are functions. Classes can get extended [1] and have a state and such. In short: Both methods and functions come from two different paradigms (OOP and procedural/functional). Just saying "static methods are just grouped functions" is a little bit to less and will always feel like a hack to me. PHP calls itself "multiparadigm", but the prodecural part feels very neglected over the time. Regards, Sebastian [1] Yes, I know, I can mark a class as "final", but this keyword is imo the most useless keyword ever ;) --- ## #54603 — Stas Malyshev — 2011-08-15T00:37:36+00:00 URL: https://externals.io/message/54425#54603 · In reply to: #54599 Hi! > I just want to use functions. Whats wrong with that? Really: Thats all. Nothing at all. But changing semantics of the language because somebody doesn't want to use existing semantics doesn't look like a good idea to me. PHP has means to do what you want to do. If you don't want to use them - well, that's your decision. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54607 — Sebastian Krebs — 2011-08-15T04:35:58+00:00 URL: https://externals.io/message/54425#54607 · In reply to: #54603 Hi, Am 15.08.2011 02:37, schrieb Stas Malyshev: > Hi! > > > > […] > > Nothing at all. But changing semantics of the language because somebody > doesn't want to use existing semantics doesn't look like a good idea to > me. PHP has means to do what you want to do. If you don't want to use > them - well, that's your decision. Now I'm getting a little bit confused: About which new/changing semantics you are talking about? I want to use custom functions, that exists, since the language itself exists, but I want to get rid of unnecessary `[include|require]_once()`-calls. I really don't see _any_ new semantics here. Regards, Sebastian --- ## #54609 — Stas Malyshev — 2011-08-15T05:23:10+00:00 URL: https://externals.io/message/54425#54609 · In reply to: #54607 Hi! > Now I'm getting a little bit confused: About which new/changing > semantics you are talking about? I want to use custom functions, that > exists, since the language itself exists, but I want to get rid of > unnecessary `[include|require]_once()`-calls. You want to change how autoloader works. This would also be a problem with global function callback for namespaces (http://www.php.net/manual/en/language.namespaces.fallback.php) since each call to, say, strlen would produce an autoloader call. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54610 — Sebastian Krebs — 2011-08-15T06:21:13+00:00 URL: https://externals.io/message/54425#54610 · In reply to: #54609 Hi, 2011/8/15 Stas Malyshev > Hi! > > > > > > […] > > You want to change how autoloader works. This would also be a problem with > global function callback for namespaces (http://www.php.net/manual/en/** > language.namespaces.fallback.**php) > since each call to, say, strlen would produce an autoloader call. I already made an suggestion [1], that bypass this. > > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > Regards, Sebastian [1] http://marc.info/?l=php-internals&m=131332512514686&w=2 --- ## #54611 — Stas Malyshev — 2011-08-15T06:48:06+00:00 URL: https://externals.io/message/54425#54611 · In reply to: #54610 Hi! > I already made an suggestion [1], that bypass this. That suggestion means you can not autoload namespaced function that overrides global function. Major WTF. Also leads to two autoload calls (one most probably resulting in exhaustive include path search) when autoloading a non-namespaced function. Pretty bad idea IMO. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54613 — Herman Radtke — 2011-08-15T07:09:15+00:00 URL: https://externals.io/message/54425#54613 · In reply to: #54611 > > […] > > That suggestion means you can not autoload namespaced function that > overrides global function. Major WTF. Also leads to two autoload calls (one > most probably resulting in exhaustive include path search) when autoloading > a non-namespaced function. Pretty bad idea IMO. It seems to me that the goal is a Python-esque approach to functions. A module (or namespace) has a number of functions, classes, etc. Once that namespace is loaded, everything is then accessible. This is similar to wrapping a number of functions within a class. The main difference is that using the namespace would allow functions to be called without a prefix. -- Herman Radtke hermanradtke@gmail.com | http://hermanradtke.com --- ## #54614 — Sebastian Krebs — 2011-08-15T07:15:44+00:00 URL: https://externals.io/message/54425#54614 · In reply to: #54611 2011/8/15 Stas Malyshev > Hi! > > > > > > […] > > That suggestion means you can not autoload namespaced function that > overrides global function. Major WTF. Imo overriding built-in functions is a WTF... Confusing others by changing the behaviour of well-known functions just sounds scary. However, when you really want to do this, than you can load your functions like before > Also leads to two autoload calls (one most probably resulting in exhaustive > include path search) when autoloading a non-namespaced function. Pretty bad > idea IMO. Please read my other mail completely: - Developers will get used to namespace everything of their stuff to avoid name conflicts (_exactly_ like it is for classes already) - Usually more than one function is loaded at once, thus you will probably safe other autoloader-calls later on. This means, there will be two calls to the autoloader _only_ when the function does not exists at all. In this case you have other problems than the two calls. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #54615 — Stas Malyshev — 2011-08-15T07:20:46+00:00 URL: https://externals.io/message/54425#54615 · In reply to: #54614 Hi! > Imo overriding built-in functions is a WTF... Confusing others by changing > the behaviour of well-known functions just sounds scary. So you want also to change namespace semantics... > However, when you really want to do this, than you can load your functions > like before So to make your scheme work properly, you need to preload... As I said, not a very good idea. I'm definitely against it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #54616 — Ferenc Kovacs — 2011-08-15T07:54:06+00:00 URL: https://externals.io/message/54425#54616 · In reply to: #54614 On Mon, Aug 15, 2011 at 9:15 AM, Sebastian Krebs wrote: > 2011/8/15 Stas Malyshev > > > […] > > > Imo overriding built-in functions is a WTF... Confusing others by changing > the behaviour of well-known functions just sounds scary. > Stas was referring to the fact that namespaces already provides this kind of monkey-patching, of course this won't work language constructs (which is a big wtf for most users in it's own way). > However, when you really want to do this, than you can load your functions > like before > > > > […] my idea was something similar what Sebastian suggested, to call the autoloader twice, but now I think that the best way would be to: 1, we check that the function exists in the current namespace 2, call the autoload callbacks with the absolute name (foo\bar\baz). 3, we check that the function exists in the global namespace this would of course mean that for every occasion when you forgot to put the \ for your global function calls your autoloader gets called, but that's a bad practice, and I really hope that the namespace fallback will be deprecated/removed in future versions. it had a nice promise: you can use namespaces without rewriting your whole application, but with the current implementation, thats simply not true_ - you have to put your namespace declaration into every file, included files won't inherit that. - you can't use the classname type constructors in namespaced code. so this is a valid concern, but I still think that the people who would use this feature could still live with either of the proposed solutions. I know that the bad decisions in the past won't count in this argument, but the current "namespace resolution falls back to the global namespace" is the one to blame for this shortcoming. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- Next page: https://externals.io/message/54425.md?page=2