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"?
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.
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
