> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
