Home » PEAR » PEAR » Bug #7255

[2006-03-30 05:52 UTC] mathieu dot bonnet at nalkym dot org

Description:
------------
AS: I report this bug as a problem with the PEAR package, as there does not seem to be any generic category which could apply to this problem, but most packages are affected... (I guess similar change requests will have to be opened for each package, when a general decision has been taken).

Using the PHP Strict Standards mode, while coding websites using PEAR packages, with >=PHP-5, is a real pain, because we get dozens of warnings for each webpage loading... it makes it hard to notice warnings in our own code (because they are lost in the flood of informations) and to get to errors (because we have to scroll large amount of text each time).

Obviously, you want to stay compatible with <PHP-5 (which is perfectly normal, as a majority of Web hosting companies still don't offer >=PHP-5), but it would be nice not to have all those warnings about problems in PEAR packages code, with >=PHP-5...

However, having two separate versions of each PEAR package would obviously be problematic for maintenance... and then most Web hosting companies who offer >=PHP-5 still offer <PHP-5, at the same time... (generally, you have to use a ".php5" file extension, to use >=PHP5... the standard ".php" extension is still linked to <PHP-5).

What about a standard header/footer, -to use in each PEAR packages file which might be included by an external file-, which would remove 2048 from the error_reporting variable, if it's higher than 2048 (when the PHP Strict Standards mode is activated), and add it again, when leaving the file? (of course, there should be an option, for PEAR developpers, to keep the PHP Stricts Standard mode activated, even for PEAR packages files... -and of course, it is not to be added to PEAR packages which are not compatible with <PHP-5, but is there any, for now?).

Or maybe a new option to the `pear` program, to automatically patch/unpatch all installed PEAR packages (to add the above-described header/footer)...

For information, warnings I get are:

- "Assigning the return value of new by reference is deprecated". (<- this one might be solved while staying compatible with <PHP-5, isn't it?)
- "var: Deprecated. Please use the public/private/protected modifiers".
- "is_a(): Deprecated. Please use the instanceof operator".

... repeated dozens of times for each webpage loading... (and I only use PEAR DB and its dependencies... what about people using... dozens of PEAR packages...?).

[2006-03-30 07:59 UTC] mathieu dot bonnet at nalkym dot org

>
> Sorry, but your problem does not imply
> a bug in PEAR itself.
>

That's why I choose "Feature/Change Request", as "Bug type", instead of "Bug"...

>
> This is a real issue, but PEAR is in transition. It
> should also be noted that PHP versions as soon as 5.1.3
> will remove E_STRICT for "var" and alias it to "public".
> This should cut down on the issue.
>

Problably... but if we use more than a few PEAR packages, other warnings will become as annoying...

(Along with the warnings I listed, there is also this one: "Non-static method PEAR::isError() should not be called statically").

>
> This, however, is not a bug in any particular package,
> as you note, and should be brought up on pear-dev instead.
>

Some example of what is in the archives:

http://www.beeblex.com/lists/index.php/php.general/210155 ("Pear DB class not PHP5 strict compatible?")
http://www.beeblex.com/lists/index.php/php.pear.dev/30915 ("PEAR.php to PHP5")
http://www.beeblex.com/lists/index.php/php.pear.dev/40011 ("move PEAR to PHP 5-only?")
http://www.beeblex.com/lists/index.php/php.pear.dev/32052 ("Forking PEAR")
http://www.beeblex.com/lists/index.php/php.pear.dev/31778 ("E_STRICT")
http://www.beeblex.com/lists/index.php/php.internals/6134 ("Compatibility problems with PHP 5")
http://www.beeblex.com/lists/index.php/php.pear.dev/41789 ("What about supporting E_STRICT error level?")
http://www.beeblex.com/lists/index.php/php.pear.dev/31115 ("how to mark protected items?")
http://www.beeblex.com/lists/index.php/php.pear.dev/33184 ("packages and php5 strict compatibility")

All those postings talk about forking or migrating to PHP-5-only, which as I noted (and as others did on the ml), is "problematic" (to say the least).

>
> Also, please don't post sweeping statements, propose
> specific solutions for specific packages, otherwise
> no one will listen to you [...]
>

As you properly noted, it is not a problem relating to any "particular package". I would have posted the issue in a more generic category, if it existed... (as said in my original report). I guess a report should be posted about the lack of a more generic "bug" category for general enhancement/change requests, but I don't have the time for this (I should be working, now).

The header/footer to deactivate/reactivate the PHP Strict Standards mode is a specific idea.

>
> [...] and it will waste bandwidth with flame wars.
>

Why would it?

- The performance cost is highly negligeable (people who care about negligeable performance costs don't use PEAR nor OOP).
- There is no BC problem, if we use the numeric value for E_STRICT (as the constant is not defined under <PHP-5).
- It should easily hold on one line (one line for the header, and another one for the footer).
- The change is independent from the rest of the code.

I don't have enough time to launch a discussion on the ml... if you don't like the idea, I'll just try to do it myself, at least manually, as a temporary solution...

[2006-03-30 09:34 UTC] mathieu dot bonnet at nalkym dot org

Ok, PHP logs some Stricts Standards mode warnings before executing the script (for "var" and "=&", but not for "is_a()", for instance), so my solution does not work as is...

The solution would be to use the "__autoload()" function and deactivate the Stricts Standards mode before including files from a PEAR package (based on the file path)... but as this solution is now completely independent from PEAR, it has indeed nothing to do here... (except if we list the solution in the FAQ or documentation...).