Re: What are the problems PEAR2 seeks to solve? [and asolution to the require_once debacle]

Alexey Borzov wrote: > Hi, > > Gregory Beaver wrote: >> It must be noted that the addition of namespaces changes a great >> deal. There is an uncommitted patch on php-internals adding autoload >> support to namespaces which will change things quite a bit. Because >> of that patch, using unqualified classnames no longer works with >> autoload if they share the same name as an internal class (like >> Exception), which will happen with this code: >> >> ... >> >> So perhaps by substituting the import statement for require_once, this >> will preserve the readability and maintainability? > > I read the php-internals threads until my head started to hurt and I'd > like to suggest once again that RFC in question should be split in > parts, with those parts that people mostly agree upon being proposed > soon and require_once-related stuff left until the proverbial dust > settles on PHP namespace implementation. OK. This is a plan. It is important to note that PEAR2 is targeting technology that is so new, we may need to retool the way things are used prior to release when we understand it better. I think it is important that this basic fact is taken into account. In other words, those developing for PEAR2 may need to make a few structural changes prior to the first truly stable release, but the goal is to keep this to a minimum, which is why these coding standard changes are being proposed now. As you recall, mandating exception usage was like pulling teeth, and is now clearly recognized as the best way to do things in PHP 5 and in PEAR, with no complaints on the mailing list for months. It's always hard to imagine what something might be like and always a bit scary to do so. One of the biggest goals of PEAR2 that I completely forgot to mention in the email I sent yesterday, as it is one of my basic assumptions, is to bring on board more of the developers who work on the core of PHP itself. PHP core and PEAR historically have had rather icy, if not downright hostile, relationship. I remember a year and a half ago, for instance, one of the more belligerent developers practically screamed at me on the internals IRC channel for mentioning PEAR, and quoted all kinds of figures in the PHP world as saying "PEAR is crap." The same person was caught using a PEAR package in his own code last week, and has been actually collaborating a bit behind the scenes on PEAR :). Other internals developers who previously would not be caught dead using PEAR have thawed in their opinions of PEAR as well, and a few are running PEAR channels for their own code. Many of the ideas in the RFC come from discussions with these developers (like Rasmus, for instance). One of the primary reasons cited is that PEAR remains PHP4-compatible. This is unfair for obvious reasons, but they feel PEAR should be supporting recent PHP development more strongly. For full disclosure, I have not formally asked for any kind of alliance or participation from core PHP devs, but if PEAR2 can be shown to actually enhance the usability of PHP for these advanced users as well as for the existing userbase, it will go a long ways towards making the repository attractive to other brilliant outsider developers who use PHP but have until now refused to touch PEAR with a 10 foot pole. Certainly, one could always rely upon other organizations like Zend or the Cake foundation to provide the latest advanced functionality of PHP, but we all know that the PHP world would suffer from the lack of the power provided by the PEAR installer, particularly in relation to managing dependencies and smooth upgrades. I know I'm biased in this regard, but those of you developing on this list are all here indirectly for these reasons as well. > In any case, thank you Greg for this in-depth description, it was really > helpful. I'll try to answer your need for clarification on the problems as soon as possible. Greg