Stanislav Malyshev wrote:
> Hi!
>
>> The caching is at runtime. Basically, it's in executor_globals, and so
>> is not linked to any opcode array (I couldn't figure out any other
>> globally accessible storage location). It works like an associative
>> array. If file X.php loads XMLReader in namespace namespacename, it
>> creates this entry:
>>
>> array(
>> 'X.php\0namespacename::XMLReader' => {class entry for XMLReader}
>> );
>
> I though a bit about that patch, and I see following problems with it:
>
> 1. If you do not use autoloading, you still can get different
> resolution, e.g.:
>
> <?php
> namespace foo;
> $a = new XMLReader;
>
> resolves to ::XMLReader and cached for this file. But suppose some other
> file, somewhere, loaded foo::XMLReader prior to that. Then the same code
> here would resolve now to foo::XMLReader as before, right?
> Isn't it the same scenario you complained about? If so this patch does
> not solve this for 100% of cases, unless I misunderstand how the patch
> works.
>
> 2. While the caching indeed helps per-file, typical OO application
> contains dozens of files, and each file may use dozens of internal
> classes (my install has 100+ internal classes). Meaning, there is still
> potential for hundreds of non-cacheable exhaustive autoload searches.
> This is not a good scenario.
Your first point is correct, and the second is interesting, but does not
quite match reality. I whipped up a script to count the number of
internal vs. user classes in a project, it's at
http://pear.php.net/~greg/detect_classes.phps
I ran it on PEAR2, which is a pre-namespace project at the moment, and
came up with these stats:
Internal classes: 239
User classes: 768
in 171 files
I ran the same script over PEAR, and got:
Internal classes: 110
User classes: 2027
in 231 files
Now, you may argue that these are atypical OO applications, so I also
ran the script over Zend Framework 1.5, with these results:
Internal classes: 950
User classes: 16167
in 1821 files
In other words, there is simply no comparison. Userspace class usage
outnumbers internal class usage by an order of magnitude in typical OO
PHP code.
PEAR2 uses an average of 2 internal classes per file, and 7 userspace
classes. PEAR uses an average of 0.5 internal classes per file, and 8
userspace classes per file. Zend Framework uses an average of 0.5
internal classes per file and ~9 userspace classes per file. Thus, if I
had to choose between defaulting to current namespace (as you suggested)
and to internal classes, the choice is easy. I would choose current
namespace because there would be far fewer use statements, and the
behavior is deterministic.
The script is at:
http://pear.php.net/~greg/detect_classes.phps
run with "php detect_classes.php /path/to/files"
Oh, and the script is one of the few cases where there are 3 internal
classes used and only 1 userspace class :).
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
