Hey Ralf (Andi et al.),
You have been putting together some points that I've been trying to
make but have come short due to lack of patience in developing the ideas
more fully. I think we are on the same page.
Yes, I too think making a Zend.php class that has multiple layers of
unrelated functionality would be a step back. I also, have heeded
Andi's, Bill's and Matthews pleas towards NOT prematurely optimizing
until a stable API... and I think that as been a 'good thing',
especially when it comes to designing a solid api we can grow with.
With that said, I offer this: I think we need to clearly define the
role of Zend.php or Zend/Core.php; which ever it may be. I personally
see it as this (and would be spelled out in the manual/tutorials/etc)
Zend/Core.php is the single place that developers can use as an entry
point into using the Zend Framework for building php based applications.
More specifically (or technically rather).. I also see it as the place
were ZendFramework CONVENTIONS meet their pragmatic counterparts. IE:
how do I load a class in the framework simply by knowing its name?
That means that the most fundamental elements of finding files that have
been placed in the framework to meet out file and class naming
conventions (consequently seen as a global utility) STAY in the Core.php
file. Why? B/c those funtions meet the technical requirements and goals
of Zend/Core.php
That also means we break out Zend_Registry functions into their
respective places, (and as Phillip mentioned on post lower, change the
static names to something more desirable get/set/has), move the version
stuff out where it belongs, and also move the debug function out to a
Debug class that is not final and can do some stuff in the future as it
relates to debugging as Rob and others have alluded to.
I personally would also like to see a method called init() in the Core
file.. this method would do the following:
static public function bootstrap($strict = false)
{
if ($strict) {
error_reporting(E_ALL | E_STRICT);
}
define('LIBRARY_PATH', dirname(dirname(__FILE__)));
ini_set('include_path', ini_get('include_path') . PATH_SEPARATOR .
LIBRARY_PATH);
return;
}
This would allow for the simplest usage in a userland bootstrap..
require_once '../application/library/Zend/Core.php';
Zend_Core::bootstrap();
.. at this points, paths have been setup (OPTIONALLY called by using
init for newbies and those who want the simplest setup), and strict mode
can be turned on, further suggesting to people to write better code ;)
but not enforcing it...
But again to reiterate, if we define a purpose for Zend/Core.php as
being the centerpoint where conventions meet practice, I can see a case
for the loading functions to stay in Core.php.
-ralph
Ralf Eggert wrote:
Hi Andi and all others,
I am sorry but I think keeping four classes in one file is even worse
than the current Zend class. Sounds a bit like premature optimization.
Many framework beginners already have problems to understand the purpose
of the Zend class. I am afraid that with your approach confusion might
even grow bigger.
One reason people almost mention when they are explaining why they favor
the Zend Framework over other frameworks is this: "because I only need
to load and use the stuff I really want to use". If someone does not
want to use the Zend_Registry why forcing him to load it on each request?
I think, Framework beginners should be told to build proper bootstrap
files to load and setup all the framework stuff they need on each
request. IMHO this is rather a task for documentation, tutorials and
sample applications than for file organization.
Someone who is really trying to tweak the performance as far as that
loading one or two files really counts, might probably be a little
annoyed to have to load Zend_Framework or Zend_Registry classes on each
request if they don't need them. These guys will tweak the framework any
way to fit their needs.
I still think that dividing the current Zend class into Zend_Loader,
Zend_Registry, etc. classes which are located in a file each, is the
better approach. And I would also favor the simple renaming of the Zend
class to a single Zend_Core class over your approach of having four
classes in one file.
Jm2c.
Thanks and Best Regards,
Ralf
