The only real reason given for Zend/Core.php containing four classes is
for performance, but I think it will actually have the opposite effect.
The only class really used in the framework is Zend_Loader. Exceptions
are lazy loaded, the Registry is a userland thing, and the
Zend_Framework class is only informational. All that is minimally needed
is Zend_Loader, so with Zend/Core.php you are actually loading a bunch
of possibly unused code every request.
Andi Gutmans wrote:
Hi Ralf and all,
Bill and I spent some time reviewing all the proposals and also
brainstorming on what we think is right for Zend Framework. Our
suggestion is very close to what Ralf is suggesting but with a few minor
tweaks.
We still believe having all the core functionality in one file is
beneficial. While we want to keep the framework as loosely coupled as
possible there are some key APIs which are pretty much used universally
throughout the framework. Breaking them each out into separate classes
and files would probably lead to a real performance hit and would
require people to require_once() all those components over and over
again (which would also be a PITA).
We therefore suggest that these key classes (previously known as Zend::)
all are put in the Zend/Core.php file.
This would not only retain good performance but it would also fit the
simplicity goal and make it easy for people to get all the necessary
infrastructure. Also, we think it'd make sense to stick Zend_Exception
there too as it also falls into the category of a class which is used
everywhere. To be clear: We are not suggesting a file which is bloated
by lots and lots of classes which aren't necessarily used. We want to
keep it lean-and-mean but with the stuff that really matters.
So the following is what it'd look like (pretty much in the spirit of
what Ralf proposed):
library/Zend/Core.php:
----------------------
class Zend_Registry {
static public function register($index, $newval) null);
static public function registry($index = null);
static public function isRegistered($index);
static public function initRegistry($registry = 'Zend_Registry');
static public function __unsetRegistry();
}
class Zend_Loader {
static public function loadClass($class, $dirs = null);
static public function loadFile($filename, $dirs = null, $once =
false);
static public function isReadable($filename);
}
class Zend_Framework {
static public function compareVersion($version)
const VERSION = '0.8.0dev';
}
class Zend_Exception { ... }
// Could live with the following outside of Core.php but it's so small
it really isn't a big deal to keep it for convenience
class Zend_Debug {
static public function dump($var, $label=null, $echo=true)
}
We have two weeks to finalize this and make all the changes (shouldn't
be too hard as it can be done with a script). We don't want to change
any APIs anymore once 0.9 is shipped but only focus on bug fixes, and
improving documentation and unit tests.
Andi
-----Original Message-----
From: Ralf Eggert [mailto:[EMAIL PROTECTED]
Sent: Monday, February 26, 2007 1:58 AM
To: [email protected]
Subject: Re: [fw-general] Request for feedback: moving
Zend.php to Zend/Zend.php
Hi,
I personally think that the proposed renaming of the Zend
class to Zend_Framework is very misleading. I would expect
that a Zend_Framework class will set up the whole framework
and not be just a funny conglomeration of methods who did not
find their way to a proper component.
Here are my suggestions:
- move Zend::register(), Zend::registry(), Zend::isRegistered(),
Zend::initRegistry() and Zend::__unsetRegistry() to Zend_Registry
- drop Zend::exception() and Zend::loadInterface()
- move Zend::loadClass(), Zend::loadFile() and Zend::isReadable() to
a new Zend_Loader class
- as suggested by others, move Zend::dump() to Zend_Debug
- the only method I am not sure about yet is
Zend::compareVersion() but
I bet we will find a solution for this as well
Like others I would also suggest to implement these changes
before the 0.9.0 beta release gets launched.
Best Regards,
Ralf
