-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Hi All,
Rob Marscher wrote:
> I think part of the concern with adding autoload directly into the
> framework is that developers might want their autoload function to
> include additional logic to allow it to work with their other
> libraries.
As far as I can see this concern can be remedied with relative ease with
some kind of "Zend_Classloader". Just of the top of my head this
functionality could be implemented with the following...
class Zend_Classloader
{
static public function getInstance(){...}
protected function __construct(){...}
protected function __clone(){...}
public function setStrategy(Zend_Classloader_Strategy_Interface
$strategy){...}
public function getStrategy(){...}
public function loadClass($name){...}
public function loadInterface($name){...}
public function autoload($name){...}
}
interface Zend_Classloader_Strategy_Interface
{
public function loadClass($name);
public function loadInterface($name);
}
class Zend_Classloader_Strategy_ZendDefault
implements Zend_Classloader_Strategy_Interface
{
public function loadClass($name)
{
Zend::loadClass($name);
}
public function loadInterface($name)
{
Zend::loadInterface($name);
}
}
The Zend_Classloader class would, upon construction, register itself
with spl_autoload_register() and set its default strategy to a new
instance of Zend_Classloader_Strategy_ZendDefault.
Now if the developer wants to include additional logic to enable it to
work with other libs then all they need to do it provide there own
strategy class.
Extending it further a Zend_Classloader_Strategy_Broker class could be
implemented to allow the application to cycle through multiple strategy's.
Now your probably thinking "But what about performance. It seems that
this introduces a lot of additional logic and most likely a lot of
file_exist checks that will only slow the application down further.".
Well depending on how how the strategy classes are implemented that my
well be the case however we can get around this by using some kind of
cache strategy...
class Zend_Classloader_Strategy_XXXCache
implements Zend_Classloader_Strategy_Interface
{
public function __construct(Zend_Classloader_Strategy_Interface
$fallback){...}
public function loadClass($name){...}
public function loadInterface($name){...}
}
The cache strategy would first lookup the class/interface name in the
cache and if found issue an include() call. If the the class/interface
name is not found then the fallback strategy would be used to load the
class/interface after which the cache strategy would use the php
reflection functionality to get the real path file name for the included
class/interface and save it into the cache.
How you implement the cache can be up to the developer and should be
designed to best suit the environment in which it will be run. A few
ideas are...
DBACache :- Uses the php dba functions to save/fetch information from a
database.
PHPFileCache :- Writes all required files into a valid php file (<?php
include '/foo/bar/a.php'; include '/foo/bar/b.php'; include
'/foo/bar/c.php';?>) which can be included as part of the application
bootstrap to provide a non conditional opcode cache friendly class
loading file.
> Several people have posted about not wanting to get too much into
> performance tweaking until the framework has neared version 1.0 and that
> Zend plans on running it through their advanced testing setup at that
> point. I guess autoloading isn't just about performance, it's about
> convenience and easy of use too...
I agree, autoloading for me is more about convenience and easy of use
then it is performance.
- --
Regards,
William Bailey.
Pro-Net Internet Services Ltd.
http://www.pro-net.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFFo3cizSfrYDJMXmERAz7AAKCssLitKRRUlqGoeLqEbN+tm/4QFACfeOBD
hMCkTCIszaY6d9vaXjioJ6c=
=1Qyl
-----END PGP SIGNATURE-----
