PEAR design and maintainability

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. Regards, Didier. _______________________________________________ Didier Villevalois - phpHeaven contributor phpMyChat & phpLang: http://www.phpheaven.net/ Stay tuned for the forthcomming phpPortal...