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:
<?php
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.
<?php
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 <namespace>\<function> exists? - Does \<function> exists? Till here everything is like usual - Try to load <namespace>\<function>. Does <namespace>\<function> exists? - Try to load \<function>. Does \<function> 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. <?php 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...@gmail.com On Fri, Aug 12, 2011 at 11:31 AM, Ferenc Kovacs<tyr...@gmail.com> wrote:On Fri, Aug 12, 2011 at 12:12 PM, Sebastian Krebs <krebs....@googlemail.com> wrote:Hi, 2011/8/12 Ferenc Kovacs<tyr...@gmail.com>On Sat, Aug 6, 2011 at 2:24 PM, Ryan McCue<li...@rotorised.com> wrote: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?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.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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
