RE: [PHP-DEV] [DRAFT] [RFC] Function autoloading
-Original Message- From: Sebastian Krebs [mailto:krebs@gmail.com] Sent: Friday, August 30, 2013 9:02 PM To: Stas Malyshev Cc: Sara Golemon; Anthony Ferrara; internals@lists.php.net Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading 2013/8/30 Stas Malyshev smalys...@sugarcrm.com Hi! Well, static methods aren't the same as functions. The big difference being? A function is stateless [1], a method isn't. A function operates only on the passed parameters [1], the method operates on the parameters and the context it inherits from the instance (non-static), or class (static and non- static). Static methods are equally stateless as global functions. A class state (static members) is no different from global variables (except for a tiny bit of lipstick in the form of encapsulation). There's no argument methods are different from global functions, not so with static methods which are essentially the same as global functions. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [DRAFT] [RFC] Function autoloading
I can accept not supporting PSR directly but implementing the class autoloader and stating internals believes autoload in should exist, just doesn't specify/support any particular implementation, this makes sense, although I like PSR and don't really see others that make (as much) sense. This means internally we recognise an issue, resolve it in a general manner and allow some decisions up to the developer. Most of us developing now have the dreaded Utils class, it's an ugly hack filled with static methods... Yes, it might be almost the same as a namespaced bunch of classes, if you don't share states between those methods. Now consider this: PSR or any autoloader implementation allows for better sharing and code reuse; AND it makes sense to allow this for OOP as well as procedural code! I think Anthony and Nikki can see the forest from the trees, and that the core should support a number of use cases, not just what you currently use (and developers miss this functionality Anthony proposes) Having namespaced functions now allows for a function autoloader that uses the namespace as the file: awesome, great, let's do this! If not by looking at others code, or at Python, or at the Class/Constants/Namespaced-Functions all needing to have and being positively impacted by an autoloader... at least try and foresee the sense it makes for non-oop-but-maintained-by-smart-people to have an autoloader! Try to understand that this need exists and, it makes sense as a step into organising and refactoring legacy applications and for structure/grouping of classes, functions and constants, if only for the sake of organisation, but also for code-sharing, code reuse AND less managing of 20 *_once calls on top of every file in legacy applications! ;) Also as a bonus, a bunch of functions/constants filled files could got through a request never being read/included if never used, this alone should warrant pause!
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
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
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
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. 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. Well, the patch needs work obviously. I'm living in a magical world where that's already been fixed. :) -Sara
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
2013/8/30 Stas Malyshev smalys...@sugarcrm.com 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? Well, static methods aren't the same as functions. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
2013/8/30 Stas Malyshev smalys...@sugarcrm.com 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). 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 9:35 AM, Sebastian Bergmann sebast...@php.netwrote: 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? 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
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 3:23 AM, Anthony Ferrara ircmax...@gmail.comwrote: 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
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 6:57 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, 2013-08-30 at 10:49 +0200, Julien Pauli wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 11:46 AM, Johannes Schlüter johan...@schlueters.de wrote: On Fri, 2013-08-30 at 10:49 +0200, Julien Pauli wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
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
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
Stas,
On Fri, Aug 30, 2013 at 12:57 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
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).
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
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: julienpa...@gmail.com [mailto:julienpa...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [DRAFT] [RFC] Function autoloading
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:br...@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: julienpa...@gmail.com [mailto:julienpa...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
Hi! Well, static methods aren't the same as functions. The big difference being? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
Hi! 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. PHP core already has autoload functionality. And I don't see how with function autoloading (which has no natural mapping at all) it is even possible to have any mapping worth including into core as a standard. Most functional code I've seen isn't even namespaced, and if you already convert old code to namespaces and need autoloading, you could as well wrap it in a class - I don't see why it's not possible. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
Hi! 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. I see a number of places where hash lookup is replaced with zend_lookup_function, not with the macro. Moreover, zend_lookup_function for some reason copies and lowercases the argument, even though for hash lookup it should already be lowercased. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
Hi! A function is stateless [1], a method isn't. A function operates only on the passed parameters [1], the method operates on the parameters and the context it inherits from the instance (non-static), or class (static and non-static). Static method is stateless in the same meaning as unattached function is. Both can keep state in static variables if you wish. So no difference at all, public static method is just a namespaced function. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Aug 30, 2013, at 10:25 AM, Stas Malyshev smalys...@sugarcrm.com wrote: 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. This sounds like a solution in search of a problem. I don't think we should create solutions for problems that do not exist and then tell people now go find some problem that may fit this neat code that I've added to the engine. We should first identify the need and only then mess with the engine, not the other way around. The problem exists: us users need a way to better organize our procedural codebases than manually managing a million require statements. You guys have now given us importing of functions, which is a great step forward. But we still need a way to intelligently load them. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 7:10 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Well, static methods aren't the same as functions. The big difference being? This seems to be the core of your argumentation in this thread: Why don't you just use Foo::bar() instead of foo\bar()? In which case, I wonder why we have functions at all. We could just use static methods instead after all. Maybe we should deprecate function support? On a more serious note: If you want an actual example of how functions can be easier to use than static methods, consider the use function RFC. Now that it's in, it is possible to directly import a function foo\bar() and use it with just bar(). Static methods allow no such thing. You always need to write the class name. The reason why people currently resort to using static methods instead of functions is the fact that there is no autoloading for functions. With autoloading, functions become a lot easier to use. Nikita
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
Hi! This seems to be the core of your argumentation in this thread: Why don't you just use Foo::bar() instead of foo\bar()? In which case, I wonder why we have functions at all. We could just use static methods instead after all. Maybe we should deprecate function support? Maybe we should stop strawman arguments? I never claimed functions should be replaced with static methods or that we should deprecate anything, please don't put words in my mouth. What I claimed is that if you write code in a *specific pattern*, that is the only pattern that makes this proposal useful and that is, as far as I can see, in no way common among people that use functions, then *in this specific case* you could as well use slightly different pattern which would allow you to use existing facilities, and the only difference between the two is the word class and using :: instead of \. On a more serious note: If you want an actual example of how functions can be easier to use than static methods, consider the use function RFC. Now that it's in, it is possible to directly import a function foo\bar() and use it with just bar(). Static methods allow no such thing. You always need to write the class name. Which is a good thing. Making different thing mean the same is not a good idea, it reduces readability. And typing 2 characters less was never a priority. The reason why people currently resort to using static methods instead of functions is the fact that there is no autoloading for functions. With autoloading, functions become a lot easier to use. I don't accept this resort to - static functions is not something that one should resort to, it is a completely valid syntactic construct. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
2013/8/30 Stas Malyshev smalys...@sugarcrm.com Hi! Well, static methods aren't the same as functions. The big difference being? A function is stateless [1], a method isn't. A function operates only on the passed parameters [1], the method operates on the parameters and the context it inherits from the instance (non-static), or class (static and non-static). [1] Beside IO and global variables-hacks -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- github.com/KingCrunch
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
Stas, I see a number of places where hash lookup is replaced with zend_lookup_function, not with the macro. Moreover, zend_lookup_function for some reason copies and lowercases the argument, even though for hash lookup it should already be lowercased. There was quite literally one place I forgot to switch to the macro expansion (in zend_API.c, zend_is_callable_check_func). I'm sorry. That has been rectified. As far as it being already lowercased, based on the original implementation before refactor, I couldn't hold that as true. So I had implemented it very similar to lookup_class. However, after the refactor (the current state of the patch), it is redundant. I have pushed a commit to refactor that away. Thanks Anthony
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
Hi! 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 It's the same as making it Functions.php and a class. I don't see why we should overhaul the autoloading in the engine and add so many complexity just to avoid writing the word class. Or, alternatively, you can keep a mapping of function-filename. There's no need or requirement for one-class, one-function or one-constant. One-class-per-file is a very frequent usage pattern. One-function-per-file never happens. That's the difference. 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. This sounds like a solution in search of a problem. I don't think we should create solutions for problems that do not exist and then tell people now go find some problem that may fit this neat code that I've added to the engine. We should first identify the need and only then mess with the engine, not the other way around. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 12:58 PM, Stas Malyshev smalys...@sugarcrm.com wrote: 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. I agree with Stas here. thanks -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
