multiple stacks, multiple versions bother anybody, or is it just me?

[Rich Kucera]

Holding all versions at 5.0.4, Multiple stacks with multiple-version
configurations inevitable

Will have to wait to see what the impact of problems such as
http://bugs.php.net/bug.php?id=33643 to the application world. We may
wait for a suitable popular resolution and jump to that version in the
future. There's already a rift between PHP4 and PHP5, and then further
developments such as these create another, splitting the camp into 4.
The fix to the language nit affects both php4 and php5 going forward,
that is it breaks a lot of existing applications. I have had apps break
due to it.

There is also a discontinuity between MySQL 4 and MySQL 5. Apparently
the upgrade is so bad that XAMPP is not releasing an upgrade patch for
it's next versions. They require you to migrate the data manually.
Future versions of XAMPP stack are in doubt, or will at least be much
more of an effort now.

We can fix up our own code to run on certain stacks or versions of PHP
and MySQL, but we can't fix up all the 3rd party software that is out
there. Given the rate of brokenness between versions of the same thing
let alone configurations of things, multiple stacks are inevitable. Is
this cost-effective?

Or am I making a mountain out of a molehill?

Best regards,
-Rich

--

http://groups.yahoo.com/group/heuristic/

[Jerry Stuckle]

Rich Kucera wrote:

Holding all versions at 5.0.4, Multiple stacks with multiple-version
configurations inevitable

Will have to wait to see what the impact of problems such as
http://bugs.php.net/bug.php?id=33643 to the application world. We may
wait for a suitable popular resolution and jump to that version in the
future. There's already a rift between PHP4 and PHP5, and then further
developments such as these create another, splitting the camp into 4.
The fix to the language nit affects both php4 and php5 going forward,
that is it breaks a lot of existing applications. I have had apps break
due to it.

There is also a discontinuity between MySQL 4 and MySQL 5. Apparently
the upgrade is so bad that XAMPP is not releasing an upgrade patch for
it's next versions. They require you to migrate the data manually.
Future versions of XAMPP stack are in doubt, or will at least be much
more of an effort now.

We can fix up our own code to run on certain stacks or versions of PHP
and MySQL, but we can't fix up all the 3rd party software that is out
there. Given the rate of brokenness between versions of the same thing
let alone configurations of things, multiple stacks are inevitable. Is
this cost-effective?

Or am I making a mountain out of a molehill?

Best regards,
-Rich

--

http://groups.yahoo.com/group/heuristic/

FWIW, I agree with the conclusion. Temporaries should not be passed as
references, either to a function or as a return value.

It won't affect my code at all, since I never did it in the first place.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Rich Kucera]

Why not? You never did this: $x = f1( f2( $y ) ); ?

For example:

$dir_path_component = array_pop( split('[/]',$dir) );

This syntax seems second nature to me. It is now broken.

You now have to inject a $foo variable into your syntax:

$dir_path_component = array_pop( $foo = split('[/]',$dir) );

Seems like other languages have solved whatever ill-effects result from
passing of function results to another function.

--

http://groups.yahoo.com/group/heuristic/

[Jerry Stuckle]

Rich Kucera wrote:

Why not? You never did this: $x = f1( f2( $y ) ); ?

For example:

$dir_path_component = array_pop( split('[/]',$dir) );

This syntax seems second nature to me. It is now broken.

You now have to inject a $foo variable into your syntax:

$dir_path_component = array_pop( $foo = split('[/]',$dir) );

Seems like other languages have solved whatever ill-effects result from
passing of function results to another function.

--

http://groups.yahoo.com/group/heuristic/

Sure - but not if f1() takes a reference. It works fine if f1() takes a
value.

For instance, what is supposed to happen if you do something like:

function f1 (&$i) {
$i++;
}

Java and C++ handle this by not allowing a temporary to be passed as a
reference (compiler error) - which is correct operation, IMHO.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Rich Kucera]

Jerry Stuckle wrote:

For instance, what is supposed to happen if you do something like:

I would like it to be run-time configurable in php.ini, where you can
opt for the old syntax where it does something reasonable which is
defined.

Before 5.0.5, it was perhaps buggy and undefined, but with a php.ini
setting you have the option to define the behavior in the case where a
function returns a temporary to a function expecting a reference.

It would be really cool to be able to set that ini option in a header
file for an application, so it wouldn't affect the entire server. Not
sure if that is possible with compiler directives.

--

http://groups.yahoo.com/group/heuristic/

[Oli Filth]

Jerry Stuckle said the following on 15/11/2005 17:09:

Rich Kucera wrote:

Why not? You never did this: $x = f1( f2( $y ) ); ?

For example:

$dir_path_component = array_pop( split('[/]',$dir) );

This syntax seems second nature to me. It is now broken.

You now have to inject a $foo variable into your syntax:

$dir_path_component = array_pop( $foo = split('[/]',$dir) );

Seems like other languages have solved whatever ill-effects result from
passing of function results to another function.

Sure - but not if f1() takes a reference. It works fine if f1() takes a
value.

For instance, what is supposed to happen if you do something like:

function f1 (&$i) {
$i++;
}

Java and C++ handle this by not allowing a temporary to be passed as a
reference (compiler error) - which is correct operation, IMHO.

Well, Java doesn't do pass by reference, but it allows pass-by-value of
references to temporary objects, e.g.:

class Donkey
{
public Donkey(String name)
{
this.name = name;
}

public String name;
}
public class test
{
static Donkey foo()
{
return new Donkey("Eeyore");
}

static void bar(Donkey d)
{
System.out.println("Donkey name: " + d.name);
}

public static void main(String[] args)
{
// pass value of reference to temp object
bar(foo());
}
}

C++ gets round this if the function is expecting a const reference, e.g.:

int foo()
{
return 4;
}

void bar (const int &i) // expecting const reference
{
printf("Value: %d\n", i);
}

int main()
{
bar(foo()); // pass temp value

return 0;
}

Obviously, PHP doesn't really do type-checking, so a PHP equivalent of
const could never be enforced.

Which is a shame, as it means that one can't differentiate between
passing by reference to eliminate object copying, and passing by
reference to allow alteration of the original object.

However, even in Jerry's example, even without the benefit of const
enforcement, I don't see why PHP can't just assign to the temporary
variable - what harm would it do?
--
Oli

[Jerry Stuckle]

Rich Kucera wrote:

Jerry Stuckle wrote:

For instance, what is supposed to happen if you do something like:

I would like it to be run-time configurable in php.ini, where you can
opt for the old syntax where it does something reasonable which is
defined.

Before 5.0.5, it was perhaps buggy and undefined, but with a php.ini
setting you have the option to define the behavior in the case where a
function returns a temporary to a function expecting a reference.

It would be really cool to be able to set that ini option in a header
file for an application, so it wouldn't affect the entire server. Not
sure if that is possible with compiler directives.

--

http://groups.yahoo.com/group/heuristic/

You mean like register_globals? Look at all the incompatibility
problems that's caused over the years!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

Oli Filth wrote:

Jerry Stuckle said the following on 15/11/2005 17:09:

Rich Kucera wrote:

Why not? You never did this: $x = f1( f2( $y ) ); ?

For example:

$dir_path_component = array_pop( split('[/]',$dir) );

This syntax seems second nature to me. It is now broken.

You now have to inject a $foo variable into your syntax:

$dir_path_component = array_pop( $foo = split('[/]',$dir) );

Seems like other languages have solved whatever ill-effects result from
passing of function results to another function.

Sure - but not if f1() takes a reference. It works fine if f1() takes
a value.

For instance, what is supposed to happen if you do something like:

function f1 (&$i) {
$i++;
}

Java and C++ handle this by not allowing a temporary to be passed as a
reference (compiler error) - which is correct operation, IMHO.

Well, Java doesn't do pass by reference, but it allows pass-by-value of
references to temporary objects, e.g.:

class Donkey
{
public Donkey(String name)
{
this.name = name;
}

public String name;
}
public class test
{
static Donkey foo()
{
return new Donkey("Eeyore");
}

static void bar(Donkey d)
{
System.out.println("Donkey name: " + d.name);
}

public static void main(String[] args)
{
// pass value of reference to temp object
bar(foo());
}
}

C++ gets round this if the function is expecting a const reference, e.g.:

int foo()
{
return 4;
}

void bar (const int &i) // expecting const reference
{
printf("Value: %d\n", i);
}

int main()
{
bar(foo()); // pass temp value

return 0;
}

Obviously, PHP doesn't really do type-checking, so a PHP equivalent of
const could never be enforced.

Which is a shame, as it means that one can't differentiate between
passing by reference to eliminate object copying, and passing by
reference to allow alteration of the original object.

However, even in Jerry's example, even without the benefit of const
enforcement, I don't see why PHP can't just assign to the temporary
variable - what harm would it do?

Yes, C++ allows a *const* reference. But it doesn't allow a non-const
reference.

But then let's take another case:

f1(3);

NOW what does f1 increment?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Oli Filth]

Jerry Stuckle said the following on 15/11/2005 20:02:

Oli Filth wrote:

Jerry Stuckle said the following on 15/11/2005 17:09:

For instance, what is supposed to happen if you do something like:

function f1 (&$i) {
$i++;
}

Java and C++ handle this by not allowing a temporary to be passed as
a reference (compiler error) - which is correct operation, IMHO.

However, even in Jerry's example, even without the benefit of const
enforcement, I don't see why PHP can't just assign to the temporary
variable - what harm would it do?

But then let's take another case:

f1(3);

NOW what does f1 increment?

Good example!

In that case, I repeat my disappointment that PHP doesn't allow one the
option to indicate a constant reference!!

Alternatively, maybe PHP should throw an error if a literal is passed
(as in your 2nd example), but cope with temporary variables - although
there's probably a caveat I'm not seeing with that either...

--
Oli

[Wayne]

On 15 Nov 2005 10:48:25 -0800, "Rich Kucera" <us*******@yahoo.com>
wrote:

I would like it to be run-time configurable in php.ini
Please god no!!!!! We've been there, we've done that. The php.ini is
not the place to put language altering directives!
It would be really cool to be able to set that ini option in a header
file for an application, so it wouldn't affect the entire server. Not
sure if that is possible with compiler directives.

I think the problem is pretty rare. You're example:

$dir_path_component = array_pop(split('[/]',$dir));

is a good one. But it's not really want you want to do here. You
don't want to pop the top element off of the result, you just want to
return the first item of it. Unfortuantely, PHP doesn't allow you to
the following:

$dir_path_component = split('[/]',$dir)[0];

However, you could write your own function to handle it cleanly. Lets
call that function array_first:

function array_first($array) {
return (isset($array[0]) ? $array[0] : null;
}

$dir_path_component = array_first(split('[/]',$dir));

Problem solved.

[Wayne]

On Tue, 15 Nov 2005 19:20:39 GMT, Oli Filth <ca***@olifilth.co.uk>
wrote:

Which is a shame, as it means that one can't differentiate between
passing by reference to eliminate object copying, and passing by
reference to allow alteration of the original object.

Since PHP uses copy-on-write semantics for all values there is no
object copying in PHP. Therefore there is no reason to references in
PHP unless you want to allow alteration of the original object. In
PHP, using references is actually more expensive than not using
references.