Andi,
I am glad you and Bill are considering alternate solutions, but I honestly
find the "multiple classes in one file" method to be more confusing than
the current state of affairs. Premature optimization.
> 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).
(And later, you said:)
> We could just go down the separation path. I'm just worried it's going
> to be a PITA to require the various classes. It also doesn't give us a
> centralized bootstrap if we require it down the road (I don't expect all
> to use the MVC).
You have said this a couple of times but I don't understand it.
I don't require_once these components over and over again. For classes
that I use on a regular basis (Zend, Zend_Registry, and so on) I do it
once--in the bootstrap. I think that's pretty standard behavior.
I can't imagine why someone would require these in individual controller
class files. It's not as if you're calling your actions without going
through the bootstrap in the first place.
You said you don't expect all to use the MVC, but I think adoption of the
framework will primarily be for new projects, and those projects will
overwhelmingly be based on the MVC pattern--I would go so far as to say
95%. Even so, it's pretty common practice for non-MVC applications to
include one file that includes all their standard included files.
Bottom line: I can't see any reason to cram multiple classes into one class.
> 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();
> }
I just want to clarify--everyone is aware that there is a Zend_Registry
class already, right? Simon implied that Zend_Registry would be a "new"
class. The existing one works perfectly well. It uses __set() and
__get(), and implements ArrayObject.
> class Zend_Loader {
> static public function loadClass($class, $dirs = null);
> static public function loadFile($filename, $dirs = null, $once =
> false);
> static public function isReadable($filename);
> }
The class could be more filled out if it were part of a Zend_FileSystem
class (in a previous e-mail I outlined some possible useful
methods/classes that could be a part of it). I am guessing most people
use loadClass() in combination with autoload--so they only refer to it
once. The method used infrequently throughout the framework itself.
> class Zend_Framework {
> static public function compareVersion($version)
> const VERSION = '0.8.0dev';
> }
Again, Zend_Environment exists for this very reason. I also don't believe
there should ever be a Zend_Framework class--too confusing.
It seems like there are a lot of opinions on this subject. Maybe there
should be some kind of vote?
-Matt
