Request for feedback: moving Zend.php to Zend/Zend.php

[Bill Karwin from Zend]

Please take a look at http://framework.zend.com/issues/browse/ZF-958

We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
class name would continue to be 'Zend', and we're not suggesting
changing any methods within the class.  Therefore no usage of this class
would change.

The only change in your application would be that you need to change
this:

  require_once 'Zend.php';

To this:

  require_once 'Zend/Zend.php';

Alternatively, you could add the 'Zend' directory to your include_path.

The benefit of this change is to simplify integration of a Zend
Framework tree in an application tree.  You could use svn externals, for
instance.

The disadvantage is that it does not follow the ZF convention that class
names always match the physical location of the class file.  But this is
the only class that needs to be an exception to this convention.

I volunteer to make this change.  I'll update other classes in the ZF
tree.  I'll write a note in the manual to tell users what they need to
do.  I'll write a docblock in Zend.php acknowledging that it is an
exception to the class-to-location convention.

If there are no strong objections, I'll make this change.

Regards,
Bill Karwin

[Shekar C Reddy]

Bill,

 

I guess this was discussed earlier and much desired. However, to work around the exception, could we look into renaming the Zend class to something like: Zend_Main or Zend_Public or Zend_Shared or Zend_Common or Zend_General or Zend_Base or Zend_Core or Zend_Standard... so the name of the file would be just: Main.php/Public.php/Shared.php/Common.php/ General.php/Base.php/Core.php/Standard.php/etc sitting in the Zend folder?

 

What do others think? Main/Public/Shared/Common/General? Votes? Ideas for more names...?

 

Regards,

 

 

On 2/25/07, Bill Karwin <[hidden email]> wrote:

Please take a look at http://framework.zend.com/issues/browse/ZF-958

We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
class name would continue to be 'Zend', and we're not suggesting
changing any methods within the class.  Therefore no usage of this class
would change.

The only change in your application would be that you need to change
this:

require_once 'Zend.php';

To this:

require_once 'Zend/Zend.php';

Alternatively, you could add the 'Zend' directory to your include_path.

The benefit of this change is to simplify integration of a Zend
Framework tree in an application tree.  You could use svn externals, for
instance.

The disadvantage is that it does not follow the ZF convention that class
names always match the physical location of the class file.  But this is
the only class that needs to be an exception to this convention.

I volunteer to make this change.  I'll update other classes in the ZF
tree.  I'll write a note in the manual to tell users what they need to
do.  I'll write a docblock in Zend.php acknowledging that it is an
exception to the class-to-location convention.

If there are no strong objections, I'll make this change.

Regards,
Bill Karwin

[qry]

I like this idea.

Shekar C Reddy <[hidden email]> wrote:

Bill,

 

I guess this was discussed earlier and much desired. However, to work around the exception, could we look into renaming the Zend class to something like: Zend_Main or Zend_Public or Zend_Shared or Zend_Common or Zend_General or Zend_Base or Zend_Core or Zend_Standard... so the name of the file would be just: Main.php/Public.php/Shared.php/Common.php/ General.php/Base.php/Core.php/Standard.php/etc sitting in the Zend folder?

 

What do others think? Main/Public/Shared/Common/General? Votes? Ideas for more names...?

 

Regards,

 

 

On 2/25/07, Bill Karwin <[hidden email]> wrote:

Please take a look at http://framework.zend.com/issues/browse/ZF-958

We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
class name would continue to be 'Zend', and we're not suggesting
changing any methods within the class.  Therefore no usage of this class
would change.

The only change in your application would be that you need to change
this:

require_once 'Zend.php';

To this:

require_once 'Zend/Zend.php';

Alternatively, you could add the 'Zend' directory to your include_path.

The benefit of this change is to simplify integration of a Zend
Framework tree in an application tree.  You could use svn externals, for
instance.

The disadvantage is that it does not follow the ZF convention that class
names always match the physical location of the class file.  But this is
the only class that needs to be an exception to this convention.

I volunteer to make this change.  I'll update other classes in the ZF
tree.  I'll write a note in the manual to tell users what they need to
do.  I'll write a docblock in Zend.php acknowledging that it is an
exception to the class-to-location convention.

If there are no strong objections, I'll make this change.

Regards,
Bill Karwin

---

Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.

[Alexander Netkachev]

On 2/26/07, Shekar C Reddy <[hidden email]> wrote:

Bill,

 

I guess this was discussed earlier and much desired. However, to work around the exception, could we look into renaming the Zend class to something like: Zend_Main or Zend_Public or Zend_Shared or Zend_Common or Zend_General or Zend_Base or Zend_Core or Zend_Standard... so the name of the file would be just: Main.php/Public.php/Shared.php/Common.php/ General.php/Base.php/Core.php/Standard.php/etc sitting in the Zend folder?

 

What do others think? Main/Public/Shared/Common/General? Votes? Ideas for more names...?

Zend_Main::dump(...); is not as good as Zend::dump(...); which I use a lot (!!!).

--
Alexander
http://www.alexatnet.com/

[Gregory Szorc-2]

I'm sold on strictly the easier svn:externals.

On 2/25/07, Bill Karwin <[hidden email]> wrote:

Please take a look at http://framework.zend.com/issues/browse/ZF-958

We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
class name would continue to be 'Zend', and we're not suggesting
changing any methods within the class.  Therefore no usage of this class
would change.

The only change in your application would be that you need to change
this:

  require_once 'Zend.php';

To this:

  require_once 'Zend/Zend.php';

Alternatively, you could add the 'Zend' directory to your include_path.

The benefit of this change is to simplify integration of a Zend
Framework tree in an application tree.  You could use svn externals, for
instance.

The disadvantage is that it does not follow the ZF convention that class
names always match the physical location of the class file.  But this is
the only class that needs to be an exception to this convention.

I volunteer to make this change.  I'll update other classes in the ZF
tree.  I'll write a note in the manual to tell users what they need to
do.  I'll write a docblock in Zend.php acknowledging that it is an
exception to the class-to-location convention.

If there are no strong objections, I'll make this change.

Regards,
Bill Karwin

[Kevin McArthur-2]

Bill,

> The benefit of this change is to simplify integration of a Zend
> Framework tree in an application tree.  You could use svn externals, for
> instance.

This brings up the question on whether this is how we want to recommend the
deployment of the framework.

I'm not recommending externals as an ideal deployment method, as it has some
issues with backwards compatibility and accidental updates when not using a
tagged version. What I've been recommending is a pear-similar global setup
using the following structure.

[]> mkdir /usr/share/php/ZendFramework
[]> cd /usr/share/php/ZendFramework
[]> wget http://framework.zend.com/download/tgz
[]> tar zxf ZendFramework-0.X.0.tar.gz

which puts the Zend.php at
/usr/share/php/ZendFramework/ZendFramework-0.X.0/library

Then during bootstrap (or via .htaccess)

$fwVersion = '0.X.0';
$fwPath = '/usr/share/php/ZendFramework';
set_include_path(get_include_path() . PATH_SEPARATOR . $fwPath .
DIRECTORY_SEPARATOR . 'ZendFramework-'. $fwVersion . DIRECTORY_SEPARATOR .
'library' );
require_once('Zend.php');

Then setup __autoload

This gives somewhat fine-grained control on a per-site basis over the fw
version the site is targeting. It also makes for patching functionality
system-wide a little simpler. I'm not against the externals method, but I'm
not sure it should be the default to include it in a standard library/Zend
directory under the source tree.

This also raises the question of how to recommend package-management
deployment of the ZendFramework. The current thoughts seem to be that an
update, updates the files in the library, but that assumes perfect backwards
compatibility and could get really messy.

Thoughts?

> The disadvantage is that it does not follow the ZF convention that class
> names always match the physical location of the class file.  But this is
> the only class that needs to be an exception to this convention.

Sounds feasible, but then will you continue to ship the fw package with a
library directory or with only a Zend directory?

Kevin McArthur


----- Original Message -----
From: "Bill Karwin" <[hidden email]>
To: <[hidden email]>
Sent: Sunday, February 25, 2007 4:27 PM
Subject: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php


Please take a look at http://framework.zend.com/issues/browse/ZF-958

We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
class name would continue to be 'Zend', and we're not suggesting
changing any methods within the class.  Therefore no usage of this class
would change.

The only change in your application would be that you need to change
this:

  require_once 'Zend.php';

To this:

  require_once 'Zend/Zend.php';

Alternatively, you could add the 'Zend' directory to your include_path.

The benefit of this change is to simplify integration of a Zend
Framework tree in an application tree.  You could use svn externals, for
instance.

The disadvantage is that it does not follow the ZF convention that class
names always match the physical location of the class file.  But this is
the only class that needs to be an exception to this convention.

I volunteer to make this change.  I'll update other classes in the ZF
tree.  I'll write a note in the manual to tell users what they need to
do.  I'll write a docblock in Zend.php acknowledging that it is an
exception to the class-to-location convention.

If there are no strong objections, I'll make this change.

Regards,
Bill Karwin

[Alexander Netkachev]

On 2/26/07, Kevin McArthur <[hidden email]> wrote:

Bill,

> The benefit of this change is to simplify integration of a Zend
> Framework tree in an application tree.  You could use svn externals, for
> instance.

This brings up the question on whether this is how we want to recommend the
deployment of the framework.

I'm not recommending externals as an ideal deployment method, as it has some
issues with backwards compatibility and accidental updates when not using a
tagged version.

Agree.

svn:externals could be configured to root of repository and those of us who wants to have updated version (I want :-) can just use this method. With properly configured include path this is not a problem. Using ZF in production and introducing to community will be simpler w/o unnecessary exceptions from the rules.

--
Alexander
http://www.alexatnet.com/

[Rob Allen-3]

Bill Karwin wrote:
> Please take a look at http://framework.zend.com/issues/browse/ZF-958
>
> We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
> class name would continue to be 'Zend', and we're not suggesting
> changing any methods within the class.  Therefore no usage of this class
> would change.


+1 to removing Zend.php from the library directory.

-1 to breaking the naming convention. Exceptions to the rule are a pain.

Regards,

Rob...

[Jan Pieper]

I don´t like it. To remain to the naming conventions you have to rename
Zend to something else. It is a major change which can crash very much
applications. Okay the framework is not final but I think it is a to big
change.

-- Jan

> Please take a look at http://framework.zend.com/issues/browse/ZF-958
>
> We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
> class name would continue to be 'Zend', and we're not suggesting
> changing any methods within the class.  Therefore no usage of this class
> would change.
>
> The only change in your application would be that you need to change
> this:
>
>   require_once 'Zend.php';
>
> To this:
>
>   require_once 'Zend/Zend.php';
>
> Alternatively, you could add the 'Zend' directory to your include_path.
>
> The benefit of this change is to simplify integration of a Zend
> Framework tree in an application tree.  You could use svn externals, for
> instance.
>
> The disadvantage is that it does not follow the ZF convention that class
> names always match the physical location of the class file.  But this is
> the only class that needs to be an exception to this convention.
>
> I volunteer to make this change.  I'll update other classes in the ZF
> tree.  I'll write a note in the manual to tell users what they need to
> do.  I'll write a docblock in Zend.php acknowledging that it is an
> exception to the class-to-location convention.
>
> If there are no strong objections, I'll make this change.
>
> Regards,
> Bill Karwin
>
>
>  

[Jan Pieper]

Ah i found what i am searching for :)

If we change Zend to something else I think we have to fix these issues:

- http://framework.zend.com/issues/browse/ZF-944
- http://framework.zend.com/issues/browse/ZF-945
- http://framework.zend.com/issues/browse/ZF-946
- http://framework.zend.com/issues/browse/ZF-947

These changes are also major changes to the framework. To get a
consitency class design we have to get strict names

-- Jan

> Please take a look at http://framework.zend.com/issues/browse/ZF-958
>
> We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
> class name would continue to be 'Zend', and we're not suggesting
> changing any methods within the class.  Therefore no usage of this class
> would change.
>
> The only change in your application would be that you need to change
> this:
>
>   require_once 'Zend.php';
>
> To this:
>
>   require_once 'Zend/Zend.php';
>
> Alternatively, you could add the 'Zend' directory to your include_path.
>
> The benefit of this change is to simplify integration of a Zend
> Framework tree in an application tree.  You could use svn externals, for
> instance.
>
> The disadvantage is that it does not follow the ZF convention that class
> names always match the physical location of the class file.  But this is
> the only class that needs to be an exception to this convention.
>
> I volunteer to make this change.  I'll update other classes in the ZF
> tree.  I'll write a note in the manual to tell users what they need to
> do.  I'll write a docblock in Zend.php acknowledging that it is an
> exception to the class-to-location convention.
>
> If there are no strong objections, I'll make this change.
>
> Regards,
> Bill Karwin
>
>
>  

[Nico Edtinger-2]

After reading the other mails:

+0   moving Zend.php - I'd use a Makefile and not svn:external
-1   renaming the class - this class is the difference between a  
library and a framework
-0.8 splitting it - same as above

nico

[26.02.2007 00:27] Bill Karwin wrote:

> Please take a look at http://framework.zend.com/issues/browse/ZF-958
>
> We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
> class name would continue to be 'Zend', and we're not suggesting
> changing any methods within the class.  Therefore no usage of this  
> class
> would change.
>
> The only change in your application would be that you need to change
> this:
>
>   require_once 'Zend.php';
>
> To this:
>
>   require_once 'Zend/Zend.php';
>
> Alternatively, you could add the 'Zend' directory to your  
> include_path.
>
> The benefit of this change is to simplify integration of a Zend
> Framework tree in an application tree.  You could use svn  
> externals, for
> instance.
>
> The disadvantage is that it does not follow the ZF convention that  
> class
> names always match the physical location of the class file.  But  
> this is
> the only class that needs to be an exception to this convention.
>
> I volunteer to make this change.  I'll update other classes in the ZF
> tree.  I'll write a note in the manual to tell users what they need to
> do.  I'll write a docblock in Zend.php acknowledging that it is an
> exception to the class-to-location convention.
>
> If there are no strong objections, I'll make this change.
>
> Regards,
> Bill Karwin

[Andries Seutens]

Hello,

In all provided solutions by other frameworkers, I still find this
solution the best one, at least for now.

Ralph E's ideas were also very good, but some components would have to
mature some further, before they would actually deserve to be a
"standalone" component. For instance take Zend_Debug: do we really want
a Zend_Debug class with only a single static method?

In my opinion, if we would move Zend::debug to a standalone component,
this would have to go through the standard proposal process, before any
drastic changes are made. Guys we are almost reaching 0.9, and changes
like those will do us more harm than good (at least in this stage).

Simply moving Zend.php only level down will save us from all the hassle,
and "quick decision" making, which isn't good anyways. One exception to
the rule ... is that so bad? Our Dutch language has more exceptions than
actual rules ...

Best,



Andries Seutens

Bill Karwin schreef:

> Please take a look at http://framework.zend.com/issues/browse/ZF-958
>
> We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
> class name would continue to be 'Zend', and we're not suggesting
> changing any methods within the class.  Therefore no usage of this class
> would change.
>
> The only change in your application would be that you need to change
> this:
>
>   require_once 'Zend.php';
>
> To this:
>
>   require_once 'Zend/Zend.php';
>
> Alternatively, you could add the 'Zend' directory to your include_path.
>
> The benefit of this change is to simplify integration of a Zend
> Framework tree in an application tree.  You could use svn externals, for
> instance.
>
> The disadvantage is that it does not follow the ZF convention that class
> names always match the physical location of the class file.  But this is
> the only class that needs to be an exception to this convention.
>
> I volunteer to make this change.  I'll update other classes in the ZF
> tree.  I'll write a note in the manual to tell users what they need to
> do.  I'll write a docblock in Zend.php acknowledging that it is an
> exception to the class-to-location convention.
>
> If there are no strong objections, I'll make this change.
>
> Regards,
> Bill Karwin
>
>
>
>  

--
Andries Seutens
http://andries.systray.be


Gecontroleerd op virussen door de JOJO Secure Gateway.

[Ramon de la Fuente]

My 2cents..

I think removing Zend.php from the main directory would make the whole
structure more daunting from the point of view of a "beginner". That
"first" file is a very easy step to mentally start grasping the
framework structure.
Also, breaking the naming convention in the very first file you
encounter is IMO a bad way to go.

That being said, as there is a lot of animo from the rest of the gang
for moving the file, I myself would opt for the name "Zend_Framework" or
"Zend_Core" (as said before that suggests "glue" or again the first
starting point), and I would also agree with moving the ::dump() method  
to a Zend_Debug class and the registry methods to Zend_Registry.

Regards,

Ramon de la Fuente


Bill Karwin wrote:

> Please take a look at http://framework.zend.com/issues/browse/ZF-958
>
> We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
> class name would continue to be 'Zend', and we're not suggesting
> changing any methods within the class.  Therefore no usage of this class
> would change.
>
> The only change in your application would be that you need to change
> this:
>
>   require_once 'Zend.php';
>
> To this:
>
>   require_once 'Zend/Zend.php';
>
> Alternatively, you could add the 'Zend' directory to your include_path.
>
> The benefit of this change is to simplify integration of a Zend
> Framework tree in an application tree.  You could use svn externals, for
> instance.
>
> The disadvantage is that it does not follow the ZF convention that class
> names always match the physical location of the class file.  But this is
> the only class that needs to be an exception to this convention.
>
> I volunteer to make this change.  I'll update other classes in the ZF
> tree.  I'll write a note in the manual to tell users what they need to
> do.  I'll write a docblock in Zend.php acknowledging that it is an
> exception to the class-to-location convention.
>
> If there are no strong objections, I'll make this change.
>
> Regards,
> Bill Karwin
>  

[André Hoffmann]

+1 on renaming Zend.php to Zend/xxx.php

(I'd go with Zend_Core)

On 2/26/07, Ramon de la Fuente <[hidden email]> wrote:

My 2cents..

I think removing Zend.php from the main directory would make the whole
structure more daunting from the point of view of a "beginner". That
"first" file is a very easy step to mentally start grasping the
framework structure.
Also, breaking the naming convention in the very first file you
encounter is IMO a bad way to go.

That being said, as there is a lot of animo from the rest of the gang
for moving the file, I myself would opt for the name "Zend_Framework" or
"Zend_Core" (as said before that suggests "glue" or again the first
starting point), and I would also agree with moving the ::dump() method
to a Zend_Debug class and the registry methods to Zend_Registry.

Regards,

Ramon de la Fuente


Bill Karwin wrote:

> Please take a look at http://framework.zend.com/issues/browse/ZF-958
>
> We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
> class name would continue to be 'Zend', and we're not suggesting
> changing any methods within the class.  Therefore no usage of this class
> would change.
>
> The only change in your application would be that you need to change
> this:
>
>   require_once ' Zend.php';
>
> To this:
>
>   require_once 'Zend/Zend.php';
>
> Alternatively, you could add the 'Zend' directory to your include_path.
>
> The benefit of this change is to simplify integration of a Zend
> Framework tree in an application tree.  You could use svn externals, for
> instance.
>
> The disadvantage is that it does not follow the ZF convention that class
> names always match the physical location of the class file.  But this is
> the only class that needs to be an exception to this convention.
>
> I volunteer to make this change.  I'll update other classes in the ZF
> tree.  I'll write a note in the manual to tell users what they need to
> do.  I'll write a docblock in Zend.php acknowledging that it is an
> exception to the class-to-location convention.
>
> If there are no strong objections, I'll make this change.
>

> Regards,
> Bill Karwin
>

--
best regards,
André Hoffmann

[Pádraic Brady]

Some javascript/style in this post has been disabled (why?)

+1

It's a minor change to move an otherwise general purpose catchall type object that can be split out if needed. Is it so hard to believe svn users could find this useful? Should we see it as acceptable to add lists of directories to our include_path? Should we use make or phing to reorganise files after even svn update? Really?

 

Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com

----- Original Message ----
From: Jim Scherer <[hidden email]>
To: [hidden email]
Sent: Monday, February 26, 2007 3:37:09 PM
Subject: Re: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php

I agree with what Ralph and now many others are saying. +1. I'm a newbie, and
like most programmers, do better with things that are logical and intuitive.
The Zend class was a bit of a mystery to me until I read this discussion. A
class named Zend meant nothing except that it was required to make the whole
thing work. If it isn't a requirement and can be replaced by Zend_Registry,
Zend_Loader, Zend_Debug I'd welcome that. And absolutely break my code and
eveyone elses, it's pre-release.

I've read from day one how you can use the entire framework or whatever
components appeal to you. Including "Zend_Loader" or "Zend_Registry" doesn't
lead me to believe that I'm getting the entire framework, but loading "Zend"
does.  To me, adding the "Zend" class to my project represented adding the
framework in its entirety. That was my misunderstanding. If you were looking
to add only a component or two, the "Zend" class might scare you off. I
recognize that the documentation is being written to demonstrate how to use
individual components, but I go to examples and index.php before
documentation, and when I see 'include "Zend.php";' I think ut-oh, I have to
include this giant file that represents the whole framework.

Jim


Ralf Eggert wrote:

>
> 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
>
>
>

--
View this message in context: http://www.nabble.com/Request-for-feedback%3A-moving-Zend.php-to-Zend-Zend.php-tf3290016s16154.html#a9160964
Sent from the Zend Framework mailing list archive at Nabble.com.

---

Don't get soaked. Take a quick peak at the forecast
with theYahoo! Search weather shortcut.

[Simon R Jones]

+1 with Ralf,

ZF is designed to be used as a component system, so why not drop Zend.php if
this is realistic to do so for 0.9. The minor changes required to our files
is quite worth it.

best wishes,
Simon

[Ralph Schindler]

Bill Karwin wrote:

> Please take a look at http://framework.zend.com/issues/browse/ZF-958
>
> We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
> class name would continue to be 'Zend', and we're not suggesting
> changing any methods within the class.  Therefore no usage of this class
> would change.
>
> The only change in your application would be that you need to change
> this:
>
>   require_once 'Zend.php';
>
> To this:
>
>   require_once 'Zend/Zend.php';

Massive -1 on this unless we decided to tackle some issues that have
been raised in the past:
   1) Zend class is very schizophrenic when it comes to its duty.
      a) it does loading of things which are possibly better suited
         for a Zend_Loader
      b) it does registry tasks that could better be implemented as
         static get/set/has/remove methods of Zend_Registry.
      c) it does dumping which would better exist inside Zend_Debug
      d) it has an exception method that has no business there anymore
   2) deployment: svn:externals IMO, is not the desired method of
distribution.  SVN, simply put, is a repository tool for the development
of code, not the distribution of code/complete solution.

Furthermore, I am not so much a fan of an exception to the rule class
without a very strong reason.  If we do wish to remove Zend.php (which I
am totally OK with since it by itself offers very little on its own..
even as 'glue'), perhaps it would be better suited as Zend/Framework.php
To me 'Framework' implies 'glue', and this would remove it from the main
directory.

If we offer this class/file as the glue to the framework, or, first file
someone is told to use in a bootstrap, I would hate to have that first
class a would-be ZendFramework user viewing be an 'exception to the
rule'... That off the bat, seems like bad form, and puts out the
perception that this framework favors lax practices over rigid
structure.  Rigid structure being a good thing for people to know what
to expect and where to expect it in this 'library'.

Thoughts?


> If there are no strong objections, I'll make this change.

Consider this my strong objection.. unless someone can enlighten me a
bit... I've been known to come around :)

> Regards,
> Bill Karwin

[Rob Allen-3]

Ralph Schindler wrote:

>   1) Zend class is very schizophrenic when it comes to its duty.
>      a) it does loading of things which are possibly better suited
>         for a Zend_Loader
>      b) it does registry tasks that could better be implemented as
>         static get/set/has/remove methods of Zend_Registry.
>      c) it does dumping which would better exist inside Zend_Debug
>      d) it has an exception method that has no business there anymore

Separate issue to the one Bill is talking about. Having said that, I
agree :) A close look at the contents of the Zend class before 1.0 would
be very wise as we'll have to live with its API after then. The things
that the Zend class is responsible for seems to have no logical basis
other than it was a place to put the code until the idea behind it could
be fleshed out.

>   2) deployment: svn:externals IMO, is not the desired method of
> distribution.  SVN, simply put, is a repository tool for the development
> of code, not the distribution of code/complete solution.

I disagree. At work, we deploy all our sites using scripts that pull
code from our CVS server. It makes moving from staging to live much less
risky for us. Having all the ZF code in library/Zend would make life
easier for those that deploy like this without impacting on any other
deployment method.


Regards,

Rob...

[Nick Lo-2]

> We propose to move Zend.php to <zf-home>/library/Zend/Zend.php.  The
> class name would continue to be 'Zend', and we're not suggesting
> changing any methods within the class.  Therefore no usage of this  
> class
> would change.

> The disadvantage is that it does not follow the ZF convention that  
> class
> names always match the physical location of the class file.  But  
> this is
> the only class that needs to be an exception to this convention.

Although I'd be happy for Zend.php to move inside Zend/ I would  
prefer that it does follow the convention. However to take it a  
little further I have previously questioned the relevance of Zend.php  
as the framework developed and therefore agree with Rob and Ralph  
here...

>>   1) Zend class is very schizophrenic when it comes to its duty.
>>      a) it does loading of things which are possibly better suited
>>         for a Zend_Loader
>>      b) it does registry tasks that could better be implemented as
>>         static get/set/has/remove methods of Zend_Registry.
>>      c) it does dumping which would better exist inside Zend_Debug
>>      d) it has an exception method that has no business there anymore
>
> Separate issue to the one Bill is talking about. Having said that, I
> agree :) A close look at the contents of the Zend class before 1.0  
> would
> be very wise as we'll have to live with its API after then. The things
> that the Zend class is responsible for seems to have no logical basis
> other than it was a place to put the code until the idea behind it  
> could
> be fleshed out.

Nick

[Stanislav Malyshev]

> Massive -1 on this unless we decided to tackle some issues that have
> been raised in the past:

I don't see much of a problem with Zend class doing a number of
functions. It's an utility class so it does a number of things, but
having class for each of these functions would not really do much use -
these functions are too small for a class, they are utilities - so
nothing wrong with having utility class. Actually, a lot of OO libraries
have a number of utility classes where they aggregate small functions.
If Zend_Debug is going to have one dump function or even two - there's
no much use of having such a class at all, Zend::dump is not worse and
we already have it.

--
Stanislav Malyshev, Zend Products Engineer
[hidden email]  http://www.zend.com/