Requiring E_STRICT Compatibility for New PEAR Packages

The issue

First stable release of PHP version 5 was done two years ago. This version of language has matured a lot throughout these two years and with PHP version 4 development effectively stopped should already be considered the preferred platform by developers of new PHP libraries and applications.

PEAR policies encourage "backwards compatibility", which unfortunately means supporting the inadequate object model of PHP version 4. While it does make sense for existing packages, requiring such "backwards compatibility" for new packages that get accepted into PEAR has at least two problems:

• It slows the adoption of PHP version 5 by users of PEAR
• PEAR risks becoming a garbage dump of obsolescent code, or at least be perceived as one

The solution

The proposed solution is to focus on "forward compatibility" instead. PHP version 5 has a builtin means to ensure that code is forward compatible, which is E_STRICT error reporting level.

Definition of E_STRICT-compatible package

The package is considered E_STRICT-compatible if

• it can be used under PHP 5.1.4+
• its files do not emit error messages when used with error reporting level set to E_ALL | E_STRICT under PHP 5.1.4+
• it follows PEAR coding standards that apply to PHP5-only packages
• it has only E_STRICT-compatible required dependencies

E_STRICT-compatible package may have optional dependencies that are not E_STRICT-compatible, but this is discouraged.

Proposed changes

After this RFC is accepted, a deadline for accepting the new non E_STRICT-compatible packages is set as January 1, 2007. This deadline should be prominently announced on PEAR website and in PEAR manual. All new PHP5-related coding standards should also be integrated into the manual.

Developers wishing to propose a new non E_STRICT-compatible package or start work on a non E_STRICT-compatible new major version (as defined in New guidelines for BC breaking releases) of an existing package should do so before the deadline.

After January 1, 2007 all new packages proposed via PEPr and all new major versions of existing packages should be E_STRICT-compatible. Proposals for non E_STRICT-compatible packages that reach this deadline not in "Called for votes" state should not be called for votes until the package is reworked to be E_STRICT-compatible.

Two versions exception: the person proposing a new package may choose to also provide a version of said package that can be run under PHP version 4. Such a version requires a separate proposal that may only be called for votes after the proposal of E_STRICT-compatible version is accepted. The package must have the name of E_STRICT-compatible version with 'PHP4' appended (ex.: Example_Foo and Example_FooPhp4).

Subpackages exception: if a package does not yet have E_STRICT-compatible version then non E_STRICT-compatible subpackages for it may be accepted at the discretion of base package's developers. If base package already has E_STRICT-compatible version then acceptance of such subpackages falls under the previous exception.

Impact on existing packages

Development and release process of existing PEAR packages which are not E_STRICT-compatible may continue as usual. The only new requirement is that if a new major version of a package is started, it should be E_STRICT-compatible.

If a new major version of an existing package was registered on PEAR website before the deadline is reached or the code of this new major version was present in PEAR CVS then this version is considered an "existing package" for the purpose of this RFC.

Nevertheless, developers of existing packages are strongly encouraged to update their packages for E_STRICT-compatibility if a BC break is still allowed by Version Naming guidelines.

Notes

Several people expressed the concern that mandating E_STRICT dependencies may slow the development. While this is true, one of the goals of this proposal is to encourage the rewrite of base PEAR classes to PHP5.

A (Non-Exhaustive) List of E_STRICT-compatibility changes

• Methods that are intended to be called statically should be defined with static keyword
• The $foo =& new Foo construct should not be used
• instanceof operator should be used instead of is_a() function
• Declarations of methods in child classes should be compatible with those in parent classes

These changes obviously imply following the Error Handling Guidelines for PHP5 packages since PEAR class itself is not E_STRICT-compatible.

Also the new object model should be taken into account: this means removing unneded references when working with objects and using clone where needed.

dark web websites