http://www.joelonsoftware.com/articles/APIWar.html

“And personally I still haven’t had time to learn .NET very deeply, and we haven’t ported Fog Creek’s two applications from classic ASP and Visual Basic 6.0 to .NET because there’s no return on investment for us. None. It’s just Fire and Motion as far as I’m concerned: Microsoft would love for me to stop adding new features to our bug tracking software and content management software and instead waste a few months porting it to another programming environment, something which will not benefit a single customer and therefore will not gain us one additional sale, and therefore which is a complete waste of several months, which is great for Microsoft, because they have content management software and bug tracking software, too, so they’d like nothing better than for me to waste time spinning cycles catching up with the flavor du jour, and then waste another year or two doing an Avalon version, too, while they add features to their own competitive software. Riiiight.“

Same issue at hand here. As you said yourself, upgrading to PHP5 is so troublesome because “errors arising from that kind of mistakes are so subtle that often things break not until a lot of lines of code later or you hardly notice that things break at all”. If I move to PHP5, I simply cannot introduce that level of instability on my users. That would be a support nightmare.

PHP4 has enough OOP features for most uses, the rest is just icing (and Java envy). PHP4 is also well known and well tested. Why introduce an unnecessary unknown into the equation?

Nobody complains about the fix of the memory leak problem, and it seems as if they found a way to work around it so you can still return new… Only it prints the stupid notice in a case where it really should not (again, I just refer to that single case).

Insisting on the point that “you shouldn’t let notices surface on a production system anyway” or “just set the error reporting level to … & ~E_NOTICE” is simply ignorant.

Now we have a large codebase and target installation systems where it is out of our control wheter 4.3.11 will remain installed (probably nobody will do if they hear “memory leak”), when the switch to 4.4 has been or will be done and what will be with future versions. We also have no influence on the error reporting level (and as to me, I want my app to be coded so well it runs without any notice at all :).

Furthermore, I could hope the PHP developers will fix the fix and release a 4.4.1 pretty soon - which I think is far from being realistic regarding the unconcerned comments I’ve read as to this issue. Fix the fix myself? Not possible, again as I have no control of the target systems.

Maybe an automated search-and-replace can “fix” my code to work around the problem. Let alone it would mean to add meaningless code - I am still unsure if there aren’t any cases where you would want to “return Factory::build()” to further indirect the creation of an instance; probably that needs a fix, too, and cannot be found that easily.

As to PHP5 - the version your customers run determines the versions you need to support. Either abandon PHP altogether and rewrite in another language. Or go for PHP5 - but you should not hope that you can live with PHP4 forever. Better act now than being urged in a few years. (Too bad that 4.4 is urgent *now* and came so unannounced that it is a real problem to get your priorities right.)

Indeed the migration is a major problem if you wrote OOP code (like we did) right from the start, and the difference between passing references or working with copies requires developers with a sound understanding of the issue. The errors arising from that kind of mistakes are so subtle that often things break not until a lot of lines of code later or you hardly notice that things break at all.

Face it. :)

If you’re writing OO code and postponed the migration to PHP5 due to the changes in OOP language features—do it now. It should be pretty the same to walk through all your “legacy” code and to add workarounds for the 4.4 bug, or just remove all the reference stuff altogether because you won’t need it in PHP5.

Hi Mpigulla,

I’m afraid the issue isn’t that straight-forward by far. I’ve been writing OO code in PHP since I started with it 5 or 6 years ago. In a very large application like mine it’s near impossible to find time to do a complete code review to ensure that the “copy -> reference” change doesn’t affect anything. It’s not as simple as removing the =& because there are places in my code where I deliberately copy objects and PHP5 would now clone in those instances for me, thus breaking my application logic. So to ensure nothing breaks I either have to find any instances of copying objects and call clone() on them, then remove the ampersand from my =& or I have to review the code even more carefully to figure out which clone()’s are necessary and which aren’t.

Either way, it’s a significant effort I don’t have time for (I already have way too much on my plate), and it’s an effort that gains myself and my users absolutely nothing. So what if it’s PHP5 compatible, that in itself has no value other than alleviating fear of being left behind in PHP4. So what value is there in sifting line-by-line through hundreds of thousands of lines of PHP code for this? The potential of finding other minor things to tweak while I’m at it? Who cares about that — it doesn’t add up. The cost of PHP5 support for significantly sized applications far outweighs any of the benefits.

As for the 4.4 bug, while a careful search-and-replace appears to be able to correct this, the fact is it shouldn’t be my responsibility to do that. PHP should support “return new SomeObject()” syntax, as it has for years. The memory leak should be fixed, not the elimination of the feature. All it’s doing is forcing us to add needless extra lines of inelegant syntax into our code because PHP as a language is really very lacklustre.

To be completely honest, the only thing that keeps me to PHP is that all my code is written in it. I looked at a rewrite a couple years ago, and it didn’t seem worth the effort. Perhaps I was wrong…

function &getFoobar() { return $o =& new Foobar(); }

This 4.4 “fix” is really silly. I agree with Harry: I don’t want to care about memory management when coding in PHP. The platform claims to take care about that. When $b =& new Foobar(); is valid and I can assign the “return” value of a new as a reference, why shouldn’t it be possible to just return the same thing (an object instance) as a reference from a function?

Of course we want to have memory leaks fixed in the platform - but not in a way that forces us to touch (in my case: a lot of) “legacy code”. Especially if it requires such silly “workarounds”. To me it seems that this workaround does - seen at the PHP language level - not make any sense. It expresses nothing. It forces me to write unneccessary constructs just to somewhere allocate some temporary
memory under the hood so that the interpreter can pass a reference around. IMHO the language should do that for me.

Please note I only refer to the case of “return new …”; something like
function foo() { return "blah"; } function bar(&$arg) { $arg = 1; } bar(foo()); is really pathologic.

Now Derick says:

The correct way to fix this function is NOT TO RETURN by reference at all! There is simply no reason for doing this.

PHP5 finally changed the way objects are passed around - with their “handles” (avoiding the word “reference” here). But the point is that the broken PHP4 way of treating objects forces you to do exactly that!

Just consider the commonly used factory pattern, which basically means you have exactly the above function returning a new something();

This function has to return a reference (and you have to assign by reference at the caller’s level). Otherwise, you will lose object identity. Consider the following code, where A might be part of a central publish/subscribe pattern where objects register themselves when being constructed.

Now that gives the notice in question and the problem is on the “return new B(…)” line.

Things come even worse: Uncomment the register… line in B’s constructor. At that moment it’s all fine, that is, code in Factory::create() will produce a warning or not depending on the implementation of B::B()! X-(

Again, the PHP4 way of treating objects requires you to pass around references almost everywhere when working with objects.

If you’re writing OO code and postponed the migration to PHP5 due to the changes in OOP language features - do it now. It should be pretty the same to walk through all your “legacy” code and to add workarounds for the 4.4 bug, or just remove all the reference stuff altogether because you won’t need it in PHP5.

Sadly enough Derick remained very vague in his announcement of 4.4.0. The announcement mail did not mention the implications with a single word.

function &getFoobar() {
return $o = new Foobar();
}

making it 3-5 chars longer. Of course the problems is solved in PHP5, at least for objects.

b4n

I believe that they should have break the backward-compatibility gospel with version 5 (which they did in a way with that php.ini setting) and go more completely in the OOP direction.

$query = end($db->get_used_queries());

The method returns an array so it should work, however 4.4 gave an error. The following worked:

$queries = $db->get_used_queries();
$query = end($queries);

Hopefully… when it’s time for 6… they just say screw it and break it all…

- Eric

The issue is not so small. I had to add 50+ lines of useless code to SimpleTest to work around it I estimate that a 40K line commercial application that I contribute to would need several thousand. That effectively blocks us from “upgrading” to 4.4. Especially as their is a compound effect with some Zend acclerator bugs that caused to put all of theose &’s in the code in the first place.

It affects the OO coders with their “&” returns worst of all. I don’t see why thye could not have fixed the fix. Or for that matter why they have taken so long to fix fundamental issues in the langauge.

yours, Marcus