Making old PEAR packages (more) E_STRICT compatible

New major packages and new major releases are required to be
E_STRICT 
compatible, and PEAR2 is visible in the horizon. But a lot
of existing 
PEAR packages will probably be around for quite a while
yet.

This is a proposal on how to fix the existing
PHP4-compatible PEAR 
packages in a way so that they remain PHP4 compatible but
can also be 
used from PHP5 with E_STRICT error reporting enabled. It
still requires 
some effort by the user, but at least the old packages no
longer prevent 
people from turning on E_STRICT error reporting.


Using a custom error handler one can mute E_STRICT errors
from 
non-E_STRICT-compliant code, e.g. PEAR. Our error handler
begins with 
something like this:

if ($errorNumber == E_STRICT &&
     (strpos($fileName, '/pear/') !== false ||
      preg_match('/^Non-static method
(DB|HTTP|Mail|PEAR)::/',
                 $message))) {
     return;
}

However, when using an opcode cache, some warnings cannot be
muted this 
way. I don't know much about the inner workings of an opcode
cache, but 
using Xcache I have found two types of warnings that are
triggered 
before I have a chance to register my own error handler:

#1. "Strict Standards: Assigning the return value of
new by reference is 
deprecated." This is caused by code like "$foo
=& new Bar()".

#2. "Strict Standards: Declaration of Bicycle::foo()
should be 
compatible with that of Vehicle::foo()". This happens
when a method is 
overridden in a child class, but the two methods take a
different number 
of arguments or similar.

These two types of errors are often easy to fix. In many
cases, the fix 
for #1 is to simply replace =& with =. #2 may be fixed
by adding dummy 
parameters to one of the methods.

Previously I have manually made these fixes to PEAR packages
in order to 
be able to use PEAR and run with E_STRICT error reporting.
The package 
owners of Mail, Net_SMTP and DB liked the idea and made
changes in 
official release:
http://pear.
php.net/bugs/bug.php?id=9947
http://pear
.php.net/bugs/bug.php?id=11581

This has been very helpful. Now the only problem for me is
the last 
lines of PEAR::raiseError(). The solution here is a bit more
tricky, 
because here it is not possible to simply replace &=
with =. A possible 
solution is to enclose the offending lines in an eval()
call, or at 
least do it for PHP4, i.e. something like this:

if (intval(PHP_VERSION) >= 5) {
     if ($skipmsg) {
         $a = new $ec($code, $mode, $options, $userinfo);
     } else {
         $a = new $ec($message, $code, $mode, $options,
$userinfo);
     }
} else {
     if ($skipmsg) {
         eval('$a = &new $ec($code, $mode, $options,
$userinfo);');
     } else {
         eval('$a = &new $ec($message, $code, $mode,
$options, 
$userinfo);');
     }
}


My suggestion is to encourage package owners to avoid using
the 
constructs #1 and #2. As mentioned, this is often quite
easy. In 
particular, the PEAR package should avoid them, as this is
required by 
all other packages.


I don't know whether the inability to mute all strict errors
is specific 
to Xcache, or whether other opcode caches have the same
problem. It has 
been a while since a ran without an opcode cache, but AFAIR
there 
weren't any problems back then. Also, I don't know whether
there are 
other constructs that has to be avoided, but so far I don't
think I have 
met any.

If somebody knows of other ways of solving this problem, I'd
be 
interested in hearing about them.


What to you think of this?


Christian

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Christian Schmidt wrote:
> New major packages and new major releases are required
to be E_STRICT
> compatible, and PEAR2 is visible in the horizon. But a
lot of existing
> PEAR packages will probably be around for quite a while
yet.
> 
> This is a proposal on how to fix the existing
PHP4-compatible PEAR
> packages in a way so that they remain PHP4 compatible
but can also be
> used from PHP5 with E_STRICT error reporting enabled.
It still requires
> some effort by the user, but at least the old packages
no longer prevent
> people from turning on E_STRICT error reporting.

[snip]

> What to you think of this?

I think that the solution is not likely to be hacking on
php4 packages
to make them less E_STRICT-able.  Pyrus is nearly ready for
a first
devel release, and the playing field for PEAR2 will be wide
open for
those who wish to E_STRICTify existing packages in a more
exciting
environment.

Thanks,
Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Gregory Beaver wrote:
> I think that the solution is not likely to be hacking
on php4 packages
> to make them less E_STRICT-able.  Pyrus is nearly ready
for a first
> devel release, and the playing field for PEAR2 will be
wide open for
> those who wish to E_STRICTify existing packages in a
more exciting
> environment.
I agree that PEAR2 is the way ahead, and I will definately
transition 
from old PEAR packages to PEAR2 equivalents as they become
available.

However, I assume it will take months or even years before
the majority 
of existing packages has been converted to PEAR2 or
PHP5-compatible PEAR 
packages. By making some mostly uncomplicated adjustments to
the 
existing packages, people can turn on E_STRICT warnings
(with a custom 
error handler) already in a few weeks. I believe this may be
attractive 
to many users.

I appreciate your work on PEAR2, and I am glad to see that
PHP5 usage is 
finally gaining som momentum. On the other hand, I think it
is worth 
spending a little effort on improving the current situation
until all 
important packages have been made PHP5-compatible. It
appears as if many 
package owners are not yet ready to abandon PHP4, and as
long as that is 
the case, I don't see any reason not to make their
PHP4-compatible 
packages slightly more "PHP5-friendly". But that
of course is the 
individual package owner's call.

I do hope, though, that you are willing to accept a patch
that removes 
E_STRICT warnings from PEAR.php (something along the lines
of what I 
mentioned in my original message) as this file is used by
all other PEAR 
packages. Then at least package owners can decide for
themselves whether 
they want to make their PHP4-compatible package
PHP5-friendly.


Christian

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Christian Schmidt wrote:
> Gregory Beaver wrote:
>> I think that the solution is not likely to be
hacking on php4 packages
>> to make them less E_STRICT-able.  Pyrus is nearly
ready for a first
>> devel release, and the playing field for PEAR2 will
be wide open for
>> those who wish to E_STRICTify existing packages in
a more exciting
>> environment.
> I agree that PEAR2 is the way ahead, and I will
definately transition
> from old PEAR packages to PEAR2 equivalents as they
become available.
> 
> However, I assume it will take months or even years
before the majority
> of existing packages has been converted to PEAR2 or
PHP5-compatible PEAR
> packages. By making some mostly uncomplicated
adjustments to the
> existing packages, people can turn on E_STRICT warnings
(with a custom
> error handler) already in a few weeks. I believe this
may be attractive
> to many users.

Hi,

If you feel these changes can be done with minimal work, no
BC issues,
and no maintenance issues, I would not oppose them. 
However, I did not
get the impression that it would be minimal.

Please feel free to open bugs for specific packages with
patches to do
this, I'm sure devs would appreciate the time and energy you
would put
into it.

> I appreciate your work on PEAR2, and I am glad to see
that PHP5 usage is
> finally gaining som momentum. On the other hand, I
think it is worth
> spending a little effort on improving the current
situation until all
> important packages have been made PHP5-compatible. It
appears as if many
> package owners are not yet ready to abandon PHP4, and
as long as that is
> the case, I don't see any reason not to make their
PHP4-compatible
> packages slightly more "PHP5-friendly". But
that of course is the
> individual package owner's call.
> 
> I do hope, though, that you are willing to accept a
patch that removes
> E_STRICT warnings from PEAR.php (something along the
lines of what I
> mentioned in my original message) as this file is used
by all other PEAR
> packages. Then at least package owners can decide for
themselves whether
> they want to make their PHP4-compatible package
PHP5-friendly.

All efforts are useful 

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

This would be usefull - especially a static infront of
getStaticProperties()

But I guess you will need to either
a) create a temporary PEAR_PHP5 package - that overwrites
PEAR.php
b) release a PHP5 only version of the PEAR package,  - which
could be 
fraught with problems (installing with PHP5 on a server
running both 
PHP4/PHP5 - breaking all code... etc.

Regards
Alan

Gregory Beaver wrote:
> Christian Schmidt wrote:
>   
>> Gregory Beaver wrote:
>>     
>>> I think that the solution is not likely to be
hacking on php4 packages
>>> to make them less E_STRICT-able.  Pyrus is
nearly ready for a first
>>> devel release, and the playing field for PEAR2
will be wide open for
>>> those who wish to E_STRICTify existing packages
in a more exciting
>>> environment.
>>>       
>> I agree that PEAR2 is the way ahead, and I will
definately transition
>> from old PEAR packages to PEAR2 equivalents as they
become available.
>>
>> However, I assume it will take months or even years
before the majority
>> of existing packages has been converted to PEAR2 or
PHP5-compatible PEAR
>> packages. By making some mostly uncomplicated
adjustments to the
>> existing packages, people can turn on E_STRICT
warnings (with a custom
>> error handler) already in a few weeks. I believe
this may be attractive
>> to many users.
>>     
>
> Hi,
>
> If you feel these changes can be done with minimal
work, no BC issues,
> and no maintenance issues, I would not oppose them. 
However, I did not
> get the impression that it would be minimal.
>
> Please feel free to open bugs for specific packages
with patches to do
> this, I'm sure devs would appreciate the time and
energy you would put
> into it.
>
>   
>> I appreciate your work on PEAR2, and I am glad to
see that PHP5 usage is
>> finally gaining som momentum. On the other hand, I
think it is worth
>> spending a little effort on improving the current
situation until all
>> important packages have been made PHP5-compatible.
It appears as if many
>> package owners are not yet ready to abandon PHP4,
and as long as that is
>> the case, I don't see any reason not to make their
PHP4-compatible
>> packages slightly more "PHP5-friendly".
But that of course is the
>> individual package owner's call.
>>
>> I do hope, though, that you are willing to accept a
patch that removes
>> E_STRICT warnings from PEAR.php (something along
the lines of what I
>> mentioned in my original message) as this file is
used by all other PEAR
>> packages. Then at least package owners can decide
for themselves whether
>> they want to make their PHP4-compatible package
PHP5-friendly.
>>     
>
> All efforts are useful 
>
> Greg
>
>   

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Gregory Beaver wrote:
> If you feel these changes can be done with minimal
work, no BC issues,
> and no maintenance issues, I would not oppose them. 
However, I did not
> get the impression that it would be minimal.

I expect only minimal changes. For instance, I filed bug
9947 about 
making these changes for the Net_SMTP and Mail packages and
then went 
out for dinner, and when I was back, the fix was committed
to CVS  
That's open source when it works!


The only two changes I am suggesting are these (unless there
are more 
problematic coding patterns that I am unaware of):
- Avoid "$foo =& new Bar()". In most cases,
this can simply be replaced 
with "$foo = new Bar()". In rare cases, the
solution is a bit more 
complicated.
- When overriding a method in a child class, make sure the
method 
signature is compatible with the method in the parent class
(this is 
generally good coding practice).


I'll post some patches soon. I hope they will be useful to
E_STRICT fans 


Christian

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 9/22/07, Christian Schmidt <pear.php.netchsc.dk> wrote:
> (...)
> What to you think of this?

To me this sounds very useful if the changes are not too
fundamental
and don't require hacking everyhing.  I think
it's painfully obvious
that PEAR2 will not start and replace PEAR(1) a 100% - so
IMHO this
aids the transition. 

Till

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Christian Schmidt wrote:
> This is a proposal on how to fix the existing
PHP4-compatible PEAR 
> packages in a way so that they remain PHP4 compatible
but can also be 
> used from PHP5 with E_STRICT error reporting enabled.
It still requires 
> some effort by the user, but at least the old packages
no longer prevent 
> people from turning on E_STRICT error reporting.

I think that's quite simple: if you want to run under
E_STRICT then don't use 
PHP4 code. If you want to use PHP4 code then don't run under
E_STRICT.

> I don't know whether the inability to mute all strict
errors is specific 
> to Xcache, or whether other opcode caches have the same
problem. It has 
> been a while since a ran without an opcode cache, but
AFAIR there 
> weren't any problems back then. Also, I don't know
whether there are 
> other constructs that has to be avoided, but so far I
don't think I have 
> met any.

Did you consult Xcache developers? Did you submit a bug
report for it? Why your 
first impulse is to "fix" PEAR for your corner
case, probably breaking it for 
some other people?

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Alexey Borzov wrote:
> I think that's quite simple: if you want to run under
E_STRICT then 
> don't use PHP4 code. If you want to use PHP4 code then
don't run under 
> E_STRICT.
Well, currently I do use PHP4 code and run with E_STRICT,
and it works 
without problems except for two lines in PEAR.php and one in
the DB 
package (and until recently a few lines in the Net_SMTP and
Mail 
packages) that I change manually upon every new release.

This works for me. My reason for suggesting it to the list
was to make 
it easier for other people to use PHP4 packages and E_STRICT
warnings.

Abandoning PHP4 code is not an option for me, since most of
the packages 
I use are only available in a PHP4 version. I could of
course turn off 
E_STRICT warnings, but I find them helpful and I would
rather manually 
fix the few problems in the source code of released packages
rather do 
without them.

I assume at least some users would prefer having E_STRICT
warnings 
turned on if possible.


> Did you consult Xcache developers? Did you submit a bug
report for it?
I submitted a bug about a related issue in eAccelerator a
while back. 
This was WONTFIXed:
https://sourcefo
rge.net/tracker/?func=detail&atid=692864&aid=1200738
&group_id=122249

I have not submitted a bug for Xcache, though. But that is
probably a 
good idea. I'll do that later.

A reason for bringing this up on the mailinglist was to hear
other 
people's experiences with other opcode caches. If the
problem can be 
avoided without changing PEAR, that is probably preferable.


> Why your first impulse is to "fix" PEAR for
your corner case, probably 
> breaking it for some other people?
After having talked to the package owners of Net_SMTP and DB
about this, 
and they both agreed to make changes to their packages, I
raised it as a 
proposal on this mailinglist a few days ago and asked for
people's thoughts.

I do by no means suggest breaking BC or anything else for
anybody.

If people oppose to the idea, I wont push it further. As
mentioned, I 
have solved my own problem.


Christian

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Christian Schmidt wrote:
>> I think that's quite simple: if you want to run
under E_STRICT then 
>> don't use PHP4 code. If you want to use PHP4 code
then don't run under 
>> E_STRICT.
> Well, currently I do use PHP4 code and run with
E_STRICT, and it works 
> without problems except for two lines in PEAR.php and
one in the DB 
> package (and until recently a few lines in the Net_SMTP
and Mail 
> packages) that I change manually upon every new
release.
> 
> This works for me.

Of course this works for you: you are running PHP5 where
"= new" and "=& new" 
are equivalent. This may break for those stuck with PHP4,
though.

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php