bootstrap classnames and include paths in config

[jkarczm]

Hi there,
Thanks for releasing 1.8.0 (and all previous versions), a quick look at the latest version made me to send two questions:

1. why bootstrap class are Zend_Application_Bootstrap_Bootstrap and Zend_Application_Bootstrap_BootstrapAbstract and not just Zend_Application_Bootstrap and Zend_Application_Bootstrap_Abstract (like other cases like i.e. Zend_View and Zend_View_Abstract)? It's not intuitive...

2. Why in config file you are using PATH_SEPARATOR for includePaths? This can be a problem if the application has to be installed on 2 different systems which uses different PATH_SEPARATOR - in such case you should use different config files for these systems, and of course it's better to have one. IMHO in Zend_Application::setIncludePaths you should use for example ";" for implode and then PATH_SEPARATOR for set_include_path as it is now

thanks
jk

[weierophinney]

-- jkarczm <jacek@...> wrote
(on Saturday, 02 May 2009, 11:22 AM -0700):
> Thanks for releasing 1.8.0 (and all previous versions), a quick look at the
> latest version made me to send two questions:
>
> 1. why bootstrap class are Zend_Application_Bootstrap_Bootstrap and
> Zend_Application_Bootstrap_BootstrapAbstract and not just
> Zend_Application_Bootstrap and Zend_Application_Bootstrap_Abstract (like
> other cases like i.e. Zend_View and Zend_View_Abstract)? It's not
> intuitive...

We're revising our naming conventions in preparation for using
namespaces with PHP 5.3. Since "Abstract" and "Interface" are reserved
keywords, we cannot use these as the final, standalone, segment of class
names. Additionally, there is some concern with using Hungarian
notation, so we are no longer accepting the term "Interface" within
interface names.

Now, as for the 'Zend_Application_Bootstrap_' prefix... This makes much
more sense when you consider it a namespace, as then each item under
that namespace has a discrete name:

    namespace zend\application\bootstrap;

    interface Bootstrapper {}
    interface ResourceBootstrapper {}
    abstract class BootstrapAbstract implements Bootstrapper, ResourceBootstrapper{}
    class Bootstrap extends BootstrapAbstract {}

The point was to keep the various classes within the same component
namespace.

We may create a 'Zend_Application_Bootstrap' in the future that extends
Zend_Application_Bootstrap_Bootstrap in order to simplify the name --
but that's still up for debate.

In the future, we will start renaming existing classes (while keeping
the originals, for BC) to follow the new conventions -- in order to ease
the transition to namespaces.

> 2. Why in config file you are using PATH_SEPARATOR for includePaths? This
> can be a problem if the application has to be installed on 2 different
> systems which uses different PATH_SEPARATOR - in such case you should use
> different config files for these systems, and of course it's better to have
> one. IMHO in Zend_Application::setIncludePaths you should use for example
> ";" for implode and then PATH_SEPARATOR for set_include_path as it is now

Can you point out where we are doing that?

Within a configuration file, you should be providing an individual path
at a time to an array:

    includePaths[] = APPLICATION_PATH "/../vendor"
    includePaths[] = APPLICATION_PATH "/../library"

This will work cross-platform, as internally we then implode() these
paths using the PATH_SEPARATOR constant. (And this is also what
Zend_Tool generates for the public/index.php file...)

--
Matthew Weier O'Phinney
Project Lead            | matthew@...
Zend Framework          | http://framework.zend.com/

[jkarczm]

Matthew Weier O'Phinney-3 wrote:

Now, as for the 'Zend_Application_Bootstrap_' prefix... This makes much
more sense when you consider it a namespace, as then each item under
that namespace has a discrete name:

    namespace zend\application\bootstrap;

    interface Bootstrapper {}
    interface ResourceBootstrapper {}
    abstract class BootstrapAbstract implements Bootstrapper, ResourceBootstrapper{}
    class Bootstrap extends BootstrapAbstract {}

The point was to keep the various classes within the same component
namespace.

Thank you for explanation. The idea looks fine, but I think that it's better for developers to use the same convention in the framework. I mean using Zend_View, Zend_Application_Bootstrap and so on in version 1.8 and rename all classes to a new convention in the next one.

Matthew Weier O'Phinney-3 wrote:

> 2. Why in config file you are using PATH_SEPARATOR for includePaths? This
> can be a problem if the application has to be installed on 2 different
> systems which uses different PATH_SEPARATOR - in such case you should use
> different config files for these systems, and of course it's better to have
> one. IMHO in Zend_Application::setIncludePaths you should use for example
> ";" for implode and then PATH_SEPARATOR for set_include_path as it is now

Can you point out where we are doing that?

Oops, my mistake, it was just a quick look and now I see that this is ok, so forget the question

regards,
jk

[weierophinney]

-- jkarczm <jacek@...> wrote
(on Sunday, 03 May 2009, 01:07 PM -0700):

> Matthew Weier O'Phinney-3 wrote:
> > Now, as for the 'Zend_Application_Bootstrap_' prefix... This makes much
> > more sense when you consider it a namespace, as then each item under
> > that namespace has a discrete name:
> >
> >     namespace zend\application\bootstrap;
> >
> >     interface Bootstrapper {}
> >     interface ResourceBootstrapper {}
> >     abstract class BootstrapAbstract implements Bootstrapper,
> > ResourceBootstrapper{}
> >     class Bootstrap extends BootstrapAbstract {}
> >
> > The point was to keep the various classes within the same component
> > namespace.
> >
>
> Thank you for explanation. The idea looks fine, but I think that it's better
> for developers to use the same convention in the framework. I mean using
> Zend_View, Zend_Application_Bootstrap and so on in version 1.8 and rename
> all classes to a new convention in the next one.

PHP 5.3 is around the corner, and we need to prepare *now*.

I made this particular decision when I did so that *new* code would
follow the new standards, and we would have the ability to gradually
rename *old* code over the next minor release or two. It will take some
time to rename the existing code, and we need to also ensure that the
original classes stick around for a while in order to retain backwards
compatibility. It makes zero sense to make the decision but not enforce
it for new code -- that just creates extra work for us in the future.

> Matthew Weier O'Phinney-3 wrote:
> >
> >> 2. Why in config file you are using PATH_SEPARATOR for includePaths? This
> >> can be a problem if the application has to be installed on 2 different
> >> systems which uses different PATH_SEPARATOR - in such case you should use
> >> different config files for these systems, and of course it's better to
> >> have
> >> one. IMHO in Zend_Application::setIncludePaths you should use for example
> >> ";" for implode and then PATH_SEPARATOR for set_include_path as it is now
> >
> > Can you point out where we are doing that?
> >
>
> Oops, my mistake, it was just a quick look and now I see that this is ok, so
> forget the question
>
> regards,
> jk
> --
> View this message in context: http://www.nabble.com/bootstrap-classnames-and-include-paths-in-config-tp23348952p23359245.html
> Sent from the Zend Core mailing list archive at Nabble.com.
>

--
Matthew Weier O'Phinney
Project Lead            | matthew@...
Zend Framework          | http://framework.zend.com/