Re: [PHP-PEAR] PEAR design and maintainability

Didier Villevalois wrote:
> 
> Hi all,
> 
> I would like that no one see any offense in what i'll say in this
> mail.
> 
> First, i'd like to say i find the PEAR initiative a great idea. I
> further think that PHP would have no future if that not a kind like
> that.
> 
> However, comming from the Java world, i can't keep wondering about PEAR
> viability. I see a big problem in how you will manage classes in the
> PEAR framework.
> 
> I know, in fact, this basicly comes from that fact there is no
> namespace support in PHP. Imagine that in the future you'd like to
> reorganise PEAR structure, look at the work you'll need to change all
> the references to these classes names not only in PEAR itself but also
> in all the using applications...
> 
> So I suggest two things:
>    - (as i've seen pear's people is also phpdev's people) you should
>    the more quickly you can implement the namespace support because
>    this is mandatory to pear's acceptation and use.
> 
>    - implement a package registry (associations name-basedir) and
>    think using a naming scheme that is close to the one of Java. This
>    naming scheme permits easy package naming, unique name waranty and
>    as a consequence extreme reusability.
> 
> I propose to organise all classes as if we have a namespace support.
> For example, for the phpHeaven Portal class:
>     org/phpHeaven/portal/Portal.php
> 
> with the exception of php/... and so on php/pear/...
> 
> This way we can easily use the include_path as a class search path.
> Locally, realy close classes would require_once themselves, and to
> access "outer" classes they would use a refashionned include_once
> function to make something like the so-called import java statement.

Hi,

PHP definitely needs real namespace support.  Zeev & Andi are not
protesting against it, they are just not in a hurry to implement it. :-(

We considered using Java-style package naming for a while, but landed on
Perl-style for various reasons.  It's easier for users to know where to
look for this way, and if a packages changes "company ownership", users
need not worry about that.  We need to provide a scheme for letting
companies define their own "corners" of the package space, though.

 - Stig