Very good point, indeed! Rigidity is recommended in cases such as security. For everything else, flexibility, user-friendliness, performance, easy-of-use and maintainability count and pay off. Reducing the number of files is a far better approach than what we thought on this thread and was also discussed earllier on this list (latency). Maybe, we could apply this approach to other classes/interfaces that go as sets, too?
We regret this thread has gone here, there and everywhere :(
I definitely don't want to be overly rigid in the framework if it comes at the expense of ease-of-use. That's exactly what Java preferred and hence it became too complicated. Actually everything we are trying to do is to be lax with the features set so that we provide a simple and easy-to-use solution.
On 2/28/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
If we separate it into separate files, what files do you see yourself requiring? What would you think the typical user will do? 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). Btw, in an answer to that Wiki entry of yours (and not necessarily related to this argument) I definitely don't want to be overly rigid in the framework if it comes at the expense of ease-of-use. That's exactly what Java preferred and hence it became too complicated. Actually everything we are trying to do is to be lax with the features set so that we provide a simple and easy-to-use solution. Andi > -----Original Message----- > From: Ralph Schindler [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 27, 2007 10:15 PM > To: [email protected] > Subject: Re: [fw-general] Request for feedback: moving > Zend.php to Zend/Zend.php > > I gotta agree with Christopher on this one.. I have zero > intentions of using the 'Registry' in 80%+ of my projects.. I > find that the controllers invoke params suit all my needs. > As for debug, I simply cant find any justification for > loading that into production/runtime.. > > To reiterate a very important point I've made in the past > (actually 2): > http://www.nabble.com/Re%3A-Request-for-feedback%3A-moving-Zen > d.php-to-Zend-Zend.php-p9152637s16154.html > > 1) this adds to the schizophrenic nature of the class. (what > does it really do?) and, > 2) its a bad thing that the first file presented to a new > ZendFrameworker is an 'exception to the rules' > > I think we should still set aside performance hacks until > later.. which ultimately seems to be the only reason for doing this. > > my 2cents. > -ralph > > Christopher Thompson wrote: > > 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. > > > > > >
