Re: DB-1.7.13 (stable) Released.

I was the one who originally proposed the change. My reasons
are 
explained in the bug report <http:/
/pear.php.net/bugs/bug.php?id=11581>. 
See also the message "[PEAR-DEV] Making old PEAR
packages (more) 
E_STRICT compatible" from 22 September 2007 on this
mailinglist.

My intention was to suggest a small BC fix.


Justin Patrin wrote:
> Various PEAR classes *will* break if code is changed to
use = rather than =&.
You are right - you cannot replace =& with = in general.
In many cases, 
though, it doesn't make a difference whether you use = og
=&, and in 
those cases I suggest using the former in order to be
"PHP5 friendly".

The relevant changes are these (did I miss some?):
http://cvs.php.net/viewvc.cgi/pear/DB/D
B/common.php?r1=1.141&r2=1.142
http://cvs.php.net/viewvc.cgi/pear/DB/DB.php?r1=
1.87&r2=1.88

I must admit that I missed the one in line 1202 of DB.php.
In general, 
you cannot be sure that the class specified by 
$db->fetchmode_object_class does not rely on using
references. So it 
looks as if that may in fact cause problems - sorry :-/. The
other 
occurrences deal with instances of DB_Result and DB_common
subclasses, 
where it doesn't make a difference whether you use =& or
= AFAICT. Or 
did I miss something?

If PHP5 friendliness is considered important, the
fetchmode_object_class 
issue can be handled in other ways.


Christian

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

On 9/24/07, Christian Schmidt <pear.php.netchsc.dk> wrote:
> I was the one who originally proposed the change. My
reasons are
> explained in the bug report <http:/
/pear.php.net/bugs/bug.php?id=11581>.
> See also the message "[PEAR-DEV] Making old PEAR
packages (more)
> E_STRICT compatible" from 22 September 2007 on
this mailinglist.
>
> My intention was to suggest a small BC fix.
>

Hmmmm, well, these changes are likely to *break* BC, not fix
it. IMHO
leaving some warnings is better than possibly breaking a lot
of code.

>
> Justin Patrin wrote:
> > Various PEAR classes *will* break if code is
changed to use = rather than =&.
> You are right - you cannot replace =& with = in
general. In many cases,
> though, it doesn't make a difference whether you use =
og =&, and in
> those cases I suggest using the former in order to be
"PHP5 friendly".

Sure, it just has to be done very carefully. There were some
nasty and
subtle bugs in some packages years ago that using =&
solved.

>
> The relevant changes are these (did I miss some?):
> http://cvs.php.net/viewvc.cgi/pear/DB/D
B/common.php?r1=1.141&r2=1.142
> http://cvs.php.net/viewvc.cgi/pear/DB/DB.php?r1=
1.87&r2=1.88
>
> I must admit that I missed the one in line 1202 of
DB.php. In general,
> you cannot be sure that the class specified by
> $db->fetchmode_object_class does not rely on using
references. So it
> looks as if that may in fact cause problems - sorry
:-/. The other
> occurrences deal with instances of DB_Result and
DB_common subclasses,
> where it doesn't make a difference whether you use
=& or = AFAICT. Or
> did I miss something?
>
> If PHP5 friendliness is considered important, the
fetchmode_object_class
> issue can be handled in other ways.
>

I think the idea of making PHP4 compatible packages PHP5
"friendly"
isn't all that useful. PHP4 packages aren't PHP5 packages
and there
are some major changes in PHP5 which make PHP4 packages
throw
warnings. I see this as simply how life is. We do have the
procedures
in place now to make new packages PHP5-only (and hence
friendly) and
efforts would be better spent creating these new packages or
upgrading
old ones rather than making changes to old packages just to
make them
throw less warnings (and possibly break BC).

-- 
Justin Patrin

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