when $a = &new class is necessary

Hi all,

As the push to make the PHP 4 code closer to PHP 5 E_STRICT
takes place,
I thought it might be helpful to have a guide for when $a =
&new class
is necessary, and when & is necessary for function
parameters that are
objects.

Read these two pages for some more insight:


http://www.php.net/manual/en/language.oop.newref.php
http://blog.libssh2.org/index.php?/archi
ves/51-Youre-being-lied-to..html

Greg

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

Gregory Beaver wrote:
> As the push to make the PHP 4 code closer to PHP 5
E_STRICT takes place,
> I thought it might be helpful to have a guide for when
$a = &new class
> is necessary, and when & is necessary for function
parameters that are
> objects.

I agree with the point raised by Justin Patrin that dealing
with 
references are somewhat risky if you are not careful.

To reduce this risk and help package owners who want to make
their PHP4 
packages "PHP5-friendly", it may be worth
introducing a utility function 
that handles the delicate art of handling PHP4 references.
For example 
replace "$foo =& new Bar($bla)" with
"$foo =& PEAR::makeNew('Bar', $bla)".

This isn't pretty, but it is less likely to have unknown
side effects 
that just replacing "$foo =& new Bar" with
"$foo = new Bar".


Christian

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

Christian Schmidt wrote:
> Gregory Beaver wrote:
>> As the push to make the PHP 4 code closer to PHP 5
E_STRICT takes place,
>> I thought it might be helpful to have a guide for
when $a = &new class
>> is necessary, and when & is necessary for
function parameters that are
>> objects.
> 
> I agree with the point raised by Justin Patrin that
dealing with
> references are somewhat risky if you are not careful.
> 
> To reduce this risk and help package owners who want to
make their PHP4
> packages "PHP5-friendly", it may be worth
introducing a utility function
> that handles the delicate art of handling PHP4
references. For example
> replace "$foo =& new Bar($bla)" with
"$foo =& PEAR::makeNew('Bar', $bla)".
> 
> This isn't pretty, but it is less likely to have
unknown side effects
> that just replacing "$foo =& new Bar"
with "$foo = new Bar".

This will replace 1 E_STRICT with another, as we won't be
able to use
the "static" keyword.

The only solution is to remove unnecessary &, and to
leave necessary &,
or to refactor so that & is not necessary.  Refactoring
is often not
possible without breaking BC, unfortunately.

Greg

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

Gregory Beaver wrote:
> This will replace 1 E_STRICT with another, as we won't
be able to use
> the "static" keyword.
Right - but the "static" warning can be muted
using a custom error 
handler, the "=&" warning can't when using an
opcode cache.


Christian

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

Christian Schmidt schrieb:
> Gregory Beaver wrote:
>> This will replace 1 E_STRICT with another, as we
won't be able to use
>> the "static" keyword.
> Right - but the "static" warning can be muted
using a custom error 
> handler, the "=&" warning can't when
using an opcode cache.
>
>
> Christian
>
But your example does not change anything. Somewhere in the
code, 
directly or within PEAR::makeNew, the  "=&
new" has to be there..

I understand PHP5 friendliness different than you, for me it
means that 
the code should act the same way on php4 and php5, which
means, the & 
needs to be used. E_STRICT is not a warning or even an
error, it is a 
help to writer better and faster php5 code.

To solve your op-code cache problem, I would suggest you to
disable 
display_errors/error_reporting, it does not affect your
custom 
error_handler in any way.

Sascha

-- 
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:
> (...)
> To reduce this risk and help package owners who want to
make their PHP4
> packages "PHP5-friendly", it may be worth
introducing a utility function
> that handles the delicate art of handling PHP4
references. For example
> replace "$foo =& new Bar($bla)" with
"$foo =& PEAR::makeNew('Bar', $bla)".

(Totally off-topic, but....)

Object factories?! IMO one of the easiest ways to make code
more complicated. 

Till

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

Sascha Grossenbacher wrote:
> But your example does not change anything. Somewhere in
the code, 
> directly or within PEAR::makeNew, the  "=&
new" has to be there..
It can be "hidden" using eval(). Something similar
happens in 
PEAR_Error, though that part of the code is deprecated. But
I agree that 
it's not pretty.

> I understand PHP5 friendliness different than you, for
me it means that 
> the code should act the same way on php4 and php5,
which means, the & 
> needs to be used.
I agree that the code should work the same on PHP4 and PHP5.
I am not 
suggesting otherwise. I only suggest dropping the
"&" where it is not 
necessary.

> To solve your op-code cache problem, I would suggest
you to disable 
> display_errors/error_reporting, it does not affect your
custom 
> error_handler in any way.
Great idea! Disabling display_errors sounds like a feasible
solution to 
the problem. My own error handler can just ignore that
setting.


Christian

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