Word of warning for anyone about to use new versions of PHP

[MiiJaySung]

I dunno if others have noticed with PHP 4.4.0 and 5.1.0b2, that they've disabled passing variables through temporaries to methods that have their data passed by reference...

eg.

<?php

function a() { return array(); }
function b(&$data) { /* ... */ }
b(a());

?>

... ends up in ...
Fatal error: Only variables can be passed by reference

the result of a() is passed to b() in a temporary passed by reference. This behaviour has been disabled in new versions of PHP. It's just a word of warning to anyone as this does break a lot of existing code.

This is all due to memory leaks caused by the reference counting in the Zend engine. What baffles e is why they can't just detect these variables and just make up some hidden anon variable name to deference into the current scope for temporaries.

[momos]

Thanks for the warning, I was about to instal 4.4. So I'd better wait a little longer...

[bonefry]

Your example is wrong, it should have been:

function &a() { return array(); }
function b(&$data) { /* ... */ }
b(a()); 

And it's a huge difference. Are you sure it doesn't work now ? (Im just too lazy to check it)

[DougBTX]

This is all due to memory leaks caused by the reference counting in the Zend engine. What baffles e is why they can't just detect these variables and just make up some hidden anon variable name to deference into the current scope for temporaries.

Do you have a link for that?

Douglas

[MiiJaySung]

Do you have a link for that?

Douglas

Not atm. I would say that what I've said though is pretty much right. I was having no end of trouble with PHP where it was leaking memory and segfaulting etc. I did a debug backtrace on PHP it's self via apachectl -X and --enable-debug in the ./configure, and traced it back to references loosing track of the reference count when the variable was used in a temporary context.

See: http://bugs.php.net/bug.php?id=32963

If you look at the source for PHP in the C code, you'll see that if you read between the lines. Because the PHP C code is pretty messy, it's hard to tell always what's going on (compare PHP's source to Ruby's C src, and Ruby's reads much cleaner)

Anyway, I reported thi behavior in the bug report below ...

http://bugs.php.net/bug.php?id=33643

and thinking about it in retrospect, this change totally ties in with the mem leak stuff they published on the main PHP.NET site, and the problems I was having, so I'm 99% sure that what I am saying is right.

Hopefully, the PHP team will change their documentation to reflect this. I'm so fed up with these sort of stupid engine level flaws/querks in PHP, that I'll be using Ruby for a lot of new things, so to some degree this doesn't affect too much I hope (any old PHP sites that need any fair amount of programming work done will gradually be migrated to RoR).

[DougBTX]

Thanks for the bugs link, will keep an eye on it. I guess this is one of the bugs/design flaws which stops you writing code like this:

class Klass {
    function talk() {
        echo 'Hello World!';
    }
}

(new Klass)->talk(); 

Re: a Ruby trick: if you have a block of ugly PHP code, comment it with a Ruby one-liner version. Takes up less space than an English description

Douglas

[MiiJaySung]

Your example is wrong, it should have been:

function &a() { return array(); }
function b(&$data) { /* ... */ }
b(a()); 

And it's a huge difference. Are you sure it doesn't work now ? (Im just too lazy to check it)

Dead certain, well with PHP 5 at least. Hardly use PHP4 now tbh

And no my example isn't wrong (It's just not efficient if you were looking at things from a C/C++ perspective). Admittedly, in most cases you would make a return by reference like you did, however if you wanted to return by value, it is perfectly legit., as a would return it's data by value, and it would copied into a temporary variable, which then gets passed by reference to b. In your case, everything is passed by reference, which is generally seen as more efficient if look things from a C perspective (the reality is that references don't really have any performance advantages in PHP unless you have really large memory blocks involved).

Anyway, the fact of the matter is, whether you write it like I did or you did, it doesn't work. You need to deference anything that was going into a temporary varaible into a varaible now. It's a pain that many people will need to have to adjust to, and I think it's a silly move of Zend from this point of view. No other language imposes this retriction (I guess C++ & C are partly an exception as most C++ programmers will dereference variables into variables before passing into parameters in order to make code exception safe from memory leaks blah blah blah)

[Dr Livingston]

compare PHP's source to Ruby's C src, and Ruby's reads much cleaner

Was wondering when Ruby would be brought into this

Re: a Ruby trick:

PHP is not Ruby, and vice versa. If it's a bug, then too bad is my thought... Is it really detrimental to your development? Doubt it somehow, sure makes no difference to me though.

[MiiJaySung]

Thanks for the bugs link, will keep an eye on it. I guess this is one of the bugs/design flaws which stops you writing code like this:

class Klass {
    function talk() {
        echo 'Hello World!';
    }
}

(new Klass)->talk(); 

Re: a Ruby trick: if you have a block of ugly PHP code, comment it with a Ruby one-liner version. Takes up less space than an English description

Douglas

LOL. Heh, that does assume that other coders are Ruby coders though I won't be using PHP for much longer. We have one very large project on PHP which needs regular updates, all the other PHP sites we have are only small and only get updeated on a monthly / yearly basis. We are in the process porting the big site to Rails as a learning curve to see how Ruby fairs for projects, (not to mention when you are learning a new system you need to be using it to really learn it). Also, on a side note, I'll be going to university in a few months anyway so I won't have as much involvement with existing PHP projects anyway.

[MiiJaySung]

Was wondering when Ruby would be brought into this

PHP is not Ruby, and vice versa. If it's a bug, then too bad is my thought... Is it really detrimental to your development? Doubt it somehow, sure makes no difference to me though.

LOL. I don't know why people are anti Ruby. PHP isn't Ruby and can't do everything Ruby does, but Ruby does 99.99% of what PHP does, so it's fair enough to do something like Doug does. Anyway, there are a lot of people who seem to be anti Ruby, yet haven't used it for anything proper. You can't really against something unless you've had a fair degree of experience imo.

[kyberfabrikken]

You can't really against something unless you've had a fair degree of experience imo.

Surely you can? If the resistance is to the change in itself. Like, if you have invested years of experience into knowing php inside-out, and you don't feel like spending a lot of time getting under the skin of yet another language. (superior as it may be).

[Luke Redpath]

Why should really getting to learn another language be such a chore though?

[lastcraft]

Hi.

The PHP community is never going to advance if it keeps losing experienced developers at the top end. It used to be that PHPers would migrate away to Java, then it was Python and now it's Ruby. The developers are not just adding a new language, but switching away from PHP. All because of Zend's cavalier attitude to language level bugs.

Perhaps the question is not "Is PHP enterprise ready?", but "Is Zend enterprise ready?".

yours, Marcus

[jplush76]

Marcus,
I agree with you and I attribute it to the immaturity of the OOP capabilities in PHP4 and lower. As you develop your skills and move to OOP concepts you realize php can only take you so far in your skillset building, however with PHP5 I think this will lessen the moving of PHP developers with the new OOP feature set.

my 2 cents

[DougBTX]

If Marcus' timeline is correct (I've not been around PHP long enough to know) then PHP5 is already two generations of leavers behind, as it seems to be heading towards Java-style OOP. There does seem to be support for that static style of OOP in the PHP community though, as you can see in the "Design an ApplicationController implementation together" thread:

public function validate(DataObject $data, ILogger $logger) 

That seems to me like a step backwards, away from the dynamic nature of PHP. And I have to agree with Marcus' analysis, language level bugs worry me.

Douglas

[Dr Livingston]

Umm...

I was only making a humourous effort in mentioning that I got the feeling that at some point Ruby would be mentioned, and my feeling was right on

I think I agree with Marcus in that Zend at the moment is not actually helping the PHP community as well as it could being doing? They are pushing PHP to the larger corporatioins I suppose to some point, but maybe they're handling the feedback they get back, badly?

They're certification program doesn't exactly put PHP in a good light either in my view. There is just something missing from it, and it doesn't do nothing for me

As for PHP <> Python <> Ruby <> Java <> ..., you do need to use the language that is best suited to the task at hand. Ruby is relatively new to a lot of web developers, and sure doesn't get the online coverage that PHP and other languages do, at the moment.

I've not used Ruby and have no intentions of doing so, as I feel PHP is capable enough but my interests lie elsewhere if I was to drop PHP in favour of something else...

[wdeboer]

Well, I am currently working with PHP4 but I would love to be able to use PHP5. The OOP support in PHP5 is just much better and more natural. Only my webserver ain't installed with PHP5, and the control panel doesn't seem to like PHP5 a lot. Oh well, maybe I should keep my fingers crossed that their will come a PHP5-based DirectAdmin version.

[DougBTX]

As for PHP <> Python <> Ruby <> Java <> ..., you do need to use the language that is best suited to the task at hand. Ruby is relatively new to a lot of web developers, and sure doesn't get the online coverage that PHP and other languages do, at the moment.

It is somewhat scary, googleing:

PHP: 330,000,000
Java: 147,000,000
Python: 35,400,000
Ruby: 14,300,000

And that the top PHP pages are actually about PHP the language, unlike for Ruby!

BTW, Google says that 1 PHP = 1 Philippine peso = 0.0177942 U.S. dollars.

Douglas

[NotThatBright]

So PHP really is worth my 2 cents!!

[DougBTX]

Can't even get 1 cup of Java for that, and think how much looking after 1 python is...

[sweatje]

1 Ruby probably costs more than the Python, though it could just eat the Ruby. Also, 1 Ruby is more expensive than 1 Pearl.

[DougBTX]

1 Ruby probably costs more than the Python, though it could just eat the Ruby.

Like getting blood from a stone

[sweatje]

FYI

http://bugs.php.net/bug.php?id=33643 is getting some play on the internals list.

[timvw]

I can say from experience that php4.4 kills simpletest and adodb..

[wdeboer]

Big chance, I am getting a new webserver with PHP5 support! Men, I can't wait