Re: Re: [PEPr] Comment on RFC::Requiring E_STRICT Compatibility for NewPEAR Packages

Lukas Smith wrote:

Joshua Eichorn wrote:

Alexey Borzov wrote:

Hi, Joshua Eichorn wrote:

What does E_Strict entail as of 5.1.4 I've looked in the PHP manual but I can't seem to find a definition of what it actually means. With var being allowed it doesn't seem like it takes much to get too E_Strict

One has to grep the source, I suppose... I did, and here are the findings: Calling functions not defined as 'static' statically Using the '=& new' construct Using deprecated is_a() Using the old-style constructor Incompatible declarations of inherited methods There are also some E_STRICT errors dealing with references and deprecated methods, but I'm not sure about the context. In a nutshell: all code that does require_once 'PEAR.php'; is not E_STRICT-compatible.

So wouldn't the simple solution be creating a php5 PEAR.php and a new include that gives you the 5 version on 5 and the current version on 4.

That would be a solution that breaks our BC standards (though maybe still sensible). But its also more related to another RFC that passed long ago on what error handling mechanism should be used for PHP5 (even if PEAR.php provides some non error handling related features). regards, Lukas It just seems silly to me to rewrite a couple hundred packages making a 1% or less change. Now we have twice the # of packages to support and we've gained nothing except for making a couple people who really like running with E_STRICT on happy.

If the goal is to increase PHP5 use, this isn't the solution. Lets use my package HTML_AJAX as an example. Its written to support php4 since I need a php4 version, im going to need a php4 version for at least another year. Now the code works in php5 already it even takes php5 into account (lots of method case problems to work through), but it doesn't work in E_STRICT from what I can tell I should be pretty darn close to supporting E_STRICT, i think the only issues I have are using old style constructors. So lets say I try to support E_STRICT and because of whatever reason (but this reason would be at most 2 or 3 lines of code) its impossible while still supporting PHP4. Why would I want to release HTML_AJAX2. Doing that would, break all the current documentation and code samples, increase confusion among my users, and mean I have to spend time keeping 2 branches in sync for at least the next year. Now there may be a handful of packages that are old and crufty and could use rewrites to get cleaned up and refactored. But what does this gain for all the packages proposed and written for php4 in the last year. Now you could say your an existing package so this doesn't matter. But if were requiring all deps to be E_STRICT then I have to create HTML_AJAX2 to support the next package like HTML_Quickform_Livesearch -josh I realize I could also do conditional includes etc to be E_STRICT compatible but that doesn't seem to be the PEAR way (and its almost as much of a pain as HTML_AJAX2) so I'm going to look at that route for now.