Previous topic

Next topic

Goals and Design

Class Naming Conventions

To understand autoloading in Zend Framework, first you need to understand the
relationship between class names and class files.

Zend Framework has borrowed an idea from » PEAR,
whereby class names have a 1:1 relationship with the filesystem. Simply put, the
underscore character ("_") is replaced by a directory separator in order to resolve
the path to the file, and then the suffix ".php" is added. For
example, the class "Foo_Bar_Baz" would correspond to
"Foo/Bar/Baz.php" on the filesystem. The assumption is also
that the classes may be resolved via PHP's
include_path setting, which allows both
include() and require() to find
the filename via a relative path lookup on the include_path.

Additionally, per PEAR as well as the » PHP project, we use and recommend
using a vendor or project prefix for your code. What this means is that all classes you
write will share a common class prefix; for example, all code in Zend Framework has the
prefix "Zend_". This naming convention helps prevent naming collisions. Within Zend
Framework, we often refer to this as the "namespace" prefix; be careful not to confuse
it with PHP's native namespace implementation.

Zend Framework follows these simple rules internally, and our coding standards encourage
that you do so as well for all library code.

Autoloader Conventions and Design

Provide namespace matching. If the class
namespace prefix is not in a list of registered namespaces, return
FALSE immediately. This allows for more optimistic
matching, as well as fallback to other autoloaders.

Allow the autoloader to act as a fallback autoloader.
In the case where a team may be widely distributed, or using an undetermined
set of namespace prefixes, the autoloader should still be configurable such
that it will attempt to match any namespace prefix. It will be noted,
however, that this practice is not recommended, as it can lead to
unnecessary lookups.

Allow toggling error suppression. We feel -- and the
greater PHP community does as well -- that error suppression
is a bad idea. It's expensive, and it masks very real application problems.
So, by default, it should be off. However, if a developer
insists that it be on, we allow toggling it on.

Allow specifying custom callbacks for autoloading.
Some developers don't want to use
Zend_Loader::loadClass() for autoloading, but still
want to make use of Zend Framework's mechanisms.
Zend_Loader_Autoloader allows specyfing an alternate
callback for autoloading.

Allow manipulation of the SPL autoload
callback chain. The purpose of this is to allow specifying
additional autoloaders -- for instance, resource loaders for classes
that don't have a 1:1 mapping to the filesystem -- to be registered before
or after the primary Zend Framework autoloader.