RE : Namespaces and __autoload()
| From: | P) | Date: | Wed, 12 Sep 2007 10:38:26 +0000 |
| Subject: | RE : Namespaces and __autoload() | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-32284@lists.php.net to get a copy of this message | ||
> From: Stanislav Malyshev [mailto:stas@zend.com]
>
> This is a good point - raising errors in chained autoloader
> makes little
> sense since next one in chain might be able to load the
> class. However,
> I am still concerned about the performance impact - exhausting all
> autoloading opportunities might be not cheap in big
> application, and it
> would be not nice if people just using something like $foo = new
> DateTime() would lose a lot of performance on it. I strive
> for "if you
> don't use it, you don't pay for it" approach - i.e. if you don't have
> own DateTime class, you shouldn't have to pay for the possibility of
> having one.
>
> > interface. So, an autoload handler like PHK's has to try both. It is
>
> What do you mean by "try both"? Could you explain a bit more on that?
Yes. PHK's autoload handler is not filename-based. It works as a (poor man's :) runtime
linker, with a symbol map. In this map, interfaces and classes have different symbol types. Today,
when this handler receives a request, it cannot know if it should look for an interface or a class.
So, it has to search both in turn.
Please consider that filename-based autoload handlers are just a primitive implementation. If you
consider only this family of handlers, that's right: getting the symbol type is not very
important. But, with smarter map-based autoload handlers, it becomes very interesting to extend the
feature to functions and, there, providing the symbol type along with the requested value becomes
mandatory.
Francois