Re: php5 packages - interfaces

Arthur Hundiak wrote:

I think Joe has raised and extremely important question: Will PEAR be forever based on PHP4 or will we eventually start seeing PHP5 specific classes taking advantage of the PHP5 enhancements? (I know we already have PHPUnit2 but that kind of lives in it's own world anyways). Certainly maintaining compatibility with PHP4 is important in the short term but is it unreasonable to target say PHP5.2 as shipping with a set of PEAR5 classes?

I'm sure it will happen before then. Of course, PHP doesn't ship with PEAR packages, only the PEAR core. Our goal is to have a PHP5-only PEAR core package by 5.2, that's for sure.

If we do accept the notion that more and more PEAR classes will require PHP5 then it might be reasonable to start planning for them. 1. Interfaces - per Joe's email.

This should be on a per-package basis. What would be good is to define a naming convention that might differentiate them from regular classes.

2. Exceptions Big thread on the internals list on using exceptions for error handling. It's not obvious how they should be used in the PEAR context.

I do believe that exceptions should be used sparingly, and never for flow control. This is absolutely crucial

3. Iterators

per-package basis

4. Class constants, overloads, autoload,abstracts,constructors,destructors,cloning - all kinds of fun

since __autoload can only be defined once, it should never be used in a PEAR package, but only in applications. everything else is per-package. Obviously, the PEAR base class should be completely avoided in PHP 5

5. Naming convention IMHO, it would be useful to rename classes to indicate they are PHP5 only. The main reason being that allowing both the old class and the new class to be used in the same script at the same time might ease migration and testing efforts. My own humble suggestion would be to just stick the number 5 after the category i.e. XML5_Parser.

This is best handled through the dependencies. Of course, being PHP5-only is obviously a BC break, so the BC-breaking release rules kick in. Greg