RE : Namespaces and __autoload()

From: 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

« previous php.internals (#32284) next »