Passing arguments by reference to functions

[Martin Lucas-Smith]

Having re-read www.php.net/functions.arguments recently, the notion of
passing arguments by reference to a function makes a lot more sense now.

However, my question is: is there any difference in outcome between:

function add_some_extra(&$string) {
$string .= 'and something extra.';
}

add_some_extra($str);

and
function add_some_extra($string) {
$string .= 'and something extra.';
return $string;
}

$str = add_some_extra($str);
other than presumably that the former is less memory-intensive?
Martin

[Sandy Lewanscheck]

Martin Lucas-Smith wrote:

Having re-read www.php.net/functions.arguments recently, the notion of
passing arguments by reference to a function makes a lot more sense now.

However, my question is: is there any difference in outcome between:

function add_some_extra(&$string) {
$string .= 'and something extra.';
}

add_some_extra($str);

and
function add_some_extra($string) {
$string .= 'and something extra.';
return $string;
}

$str = add_some_extra($str);

Hi,

there is no difference really i would say.
Calling by Reference also doesn't make much
sense here.
But imagine you have an object you would like
to manipulate inside another object.
There you would pass the other object by reference.
For instance if you have an object car and inside you
want to create 4 objects of the type wheel.
Then i would make the wheels and save them
as References.
Otherwise you would lose them
after you leave the car constructor...
ehmmm... jeez... :) that sounds confusing...? :)

Sandy

[Jochen Buennagel]

Martin Lucas-Smith wrote:

other than presumably that the former is less memory-intensive?

It is not. It has something to do with the extra smart
copy-on-write-reference-counting mechanism that the Zend engine uses.
You can read it up in "Core PHP", which also has a full explanation of
the reasons under the heading "Don't Trust Your Instincts".

But much worse is IMHO the fact that you can't use literals as
arguments, like somefunction(array('a','b')).

Jochen

[Savut]

it just depend on what kind of treatement you want to do on the object passed to the function.
If you want to treat the same object than the original then you use reference, if you are about treating a copy, then you dont use
reference. If you pass a car to the function using reference then if inside the function you change the wheels, then when you exit
the function, the original car will also have the wheels changed.

Savut

"Jochen Buennagel" <za**@buennagel.com> a écrit dans le message de news:br*************@news.t-online.com...

Martin Lucas-Smith wrote:

other than presumably that the former is less memory-intensive?

It is not. It has something to do with the extra smart
copy-on-write-reference-counting mechanism that the Zend engine uses.
You can read it up in "Core PHP", which also has a full explanation of
the reasons under the heading "Don't Trust Your Instincts".

But much worse is IMHO the fact that you can't use literals as
arguments, like somefunction(array('a','b')).

Jochen

[Bruno Desthuilliers]

Martin Lucas-Smith wrote:

Having re-read www.php.net/functions.arguments recently, the notion of
passing arguments by reference to a function makes a lot more sense now.

However, my question is: is there any difference in outcome between:
function add_some_extra(&$string) {
$string .= 'and something extra.';
}

add_some_extra($str);

and
function add_some_extra($string) {
$string .= 'and something extra.';
return $string;
}

$str = add_some_extra($str);

There's at least three *major* diffs : the second version
- does not have side-effect, which means you *don't* modify the argument
(and this is a Good Thing(tm)).

- return something, which means you can do thangs like :
$mystr ="here is a string ";
print add_some_extra($mystr)

- can be used with litterals, ie :
print add_some_extra("here is another string");

So the second version is IMHO *much* more clean and useful.
other than presumably that the former is less memory-intensive?

Here you maybe wrong... (see other posts in this thread).

Bruno