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