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/

[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

[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

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

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

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

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

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

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

[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

[Ralf Eggert]

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

[Andrew Yager]

Hi All,

On 26/02/2007, at 8:58 PM, Ralf Eggert wrote:

> 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

I think that these suggestions are good. (and I must incidentally put my
support keeping the convention, rather than breaking it.)

Perhaps Zend::compareVersion would be best to put into a Zend_Framework
class as it seems to be a logical framework type function.

> Like others I would also suggest to implement these changes before the
> 0.9.0 beta release gets launched.

The sooner these changes can be made the better.

Andrew

[Martin Martinov-2]

On 26/02/07, Andrew Yager <[hidden email]> wrote:

> Hi All,
>
> On 26/02/2007, at 8:58 PM, Ralf Eggert wrote:
>
> > 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
>
> I think that these suggestions are good. (and I must incidentally put my
> support keeping the convention, rather than breaking it.)
>
> Perhaps Zend::compareVersion would be best to put into a Zend_Framework
> class as it seems to be a logical framework type function.
>
> > Like others I would also suggest to implement these changes before the
> > 0.9.0 beta release gets launched.
>
> The sooner these changes can be made the better.
>
> Andrew
>
>

That's the best way to go IMHO. Zend_Loader sounds well, and the same
goes to the other proposed class names. Just wanted to express my
support for this idea.


--
Regards,
Martin Martinov

[Simon Mundy]

ALthough it's still currently 'to do', the following will work as of 0.9

$environment = new Zend_Environment(new Zend_Environment_Core
('framework'));

if ($environment->framework->isVersion('0.9')) {
     ....
}

> - the only method I am not sure about yet is Zend::compareVersion()  
> but
>   I bet we will find a solution for this as well

--

Simon Mundy | Director | PEPTOLAB

""" " "" """""" "" "" """"""" " "" """"" " """"" "  """""" "" "
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice [phone] | Mobile [phone] | Fax [phone]  
4124
http://www.peptolab.com

[Philip Iezzi]

Here's my +1 for Ralf's proposal!

Actually, I liked the way of using an entry class. But I just liked it as there were not enough real-world examples around at the time I started to work with ZF 0.1.5. For a beginner a Zend class entry point definitely makes sense. It's always nice to "have something in your hands". But all this just because of a lack of documentation. Things have changed and the Zend developers lately focused a lot on documentation. Also by the 1.0 release there will be a lot of real-world sample applications around and nobody is afraid any more of using Zend_Registry instead of an inconsistent schizophrenic Zend base class.

I still believe we need to write a lot of bootstrap & application structure recommendations for various use cases. But we are not yet at 1.0.
And besides, below-1.0 there is no arguing "help, it will break my code!" if we are facing an important change towards better consistency.

Regards,
Philip


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
>

[Tautvydas Andrikys]

Hi,

I think the best solution would be to change naming conventions, so that
the main class of a package would be in package directory, like in Java.
And as Ralf suggested class Zend could be removed.
So:
Zend/Db.php => Zend/Db/Db.php,
Zend/Db/Table.php => Zend/Db/Table/Table.php
...

This way use of one separate framework package would be much easier: it
would be enough to copy directory[now we need to copy directory and one
.php class file] and there would be much cleaner package separation.

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

Tautvydas Andrikys aka esminis

[tautvydas.vcf]

---

begin:vcard
fn:Tautvydas Andrikys
n:Andrikys;Tautvydas
org:M2 Technologijos;Programming
adr;quoted-printable:;;Laisv=C4=97s pr. 77B;Vilnius;;;Lithuania
email;internet:[hidden email]
title:Programmer
tel;work:00 370 5 2462284
tel;fax:[phone]
tel;cell:00 370 671 52246
x-mozilla-html:FALSE
url:http://www.m2.lt
version:2.1
end:vcard

---