Zeev Suraski wrote:
Let me let you in on a secret as well. This tone isn't going to get you
anywhere.
No it won't. But the diplomatic one didn't get us anything except
insults and put downs. This approach has at least got some serious
attention. :)
For the record, I was against fixing this issue in the 4.x branch, both
because of binary compatibility breakage and because of the mess it's
likely to create. That said, it's not one of the cases where I followed
my position all the way through, because the opposite opinion had quite
enough weight behind it too.
I don't particularly like the "Not Our Problem" attitude of some of the
PHP developers any more than you do. However, you essentially argue the
same thing exactly, so I don't find it very easy to sympathize with you,
either.
Any time a change of this nature is made the PHP programmers are the
ones who have to wear the time and expense of upgrading. We can
understand there will be BC issues when doing a major version upgrade,
like PHP4 to PHP5. That is to be expected. However, for those who don't
have the time to make that change they should expect to have a stable
php4 branch that never has any BC issues.
If PHP ever wants to be considered an enterprise level application then
there are certain things that the PHP developers must deliver in.
1) The most obvious, and probably the least important is the actual
product and tools.
2) The support. It already has fantastic documentation. It's one of the
things that people immediatly notice when they first use it. But that is
only a small part of it. A major part is how the developers interact
with the users. If you have people like Derick insulting your users and
telling them to STFU then you have to have serious words with him, and
if necessary get rid of his arse, because he represents you. The image
he projects to people they will take and apply to all of you, like I
just did. People like him will never help you solve a problem. They will
only ever escalate them.
Next, get a bug system that is actually useful. Time and time again
people submit legitimate bugs on to have them marked as bogus, or won't
fix. Maybe there is a legit reason for that, but it's never explained
except by some arrogant "There's nothing critical here, fix your
scripts" type comment that explains nothing about what is wrong with the
script, or a reference to the relevant documentation that explains it.
That doesn't exactly promote a healthy relationship between the
developers and your users. Right now you have a clique, where only
trusted members of the magic circle have any hope of submitting
successful bugs. I exagerate of course, but not by much.
3) Most importantly, professionalism in your development. Part of that
is a stable API. Programmers cannot, and *will not* develop for a moving
target. BC *must* be your number 1 priority. Just today I had people
email me basically saying that it's too late. There are too many viable
options out there to warrant sticking with the relatively fragile and
limited PHP platform. "Change to Ruby. It's heaps better!"
I will tell you right now that I have considered it. PHP is becoming
random and difficult to predict. But I don't want to give up just yet
because I have invested too much time and money into major projects.
Now I know a lot of things are inconsistant for historical reasons, but
there is no reason to introduce more.
The changes you have just introduced tell us that this:
function &getProcessor()
{
return $this->processor->getInstance();
}
has to be changed to this:
function &getProcessor()
{
$instance =& $this->processor->getInstance();
return $instance;
}
Logically those two functions are exactly the same. Ignoring the memory
issue, in 4.3 they are exactly the same. Now if those functions didn't
use references then this is valid with no warning generated:
function getProcessor()
{
return $this->processor->getInstance();
}
Now explain to a student who is new to programing the logic behind one
version being perfectly valid, and the other version being incorrect.
They will probably look at you sideways and say something like "But that
makes no sense!" and they will be correct.
The question of whether or not we should fix a problem that *definitely*
causes memory corruption in certain situations, but that's likely to
break applications that relied on this behavior, is not a very easy
one. But deciding in favour of fixing the corruption is definitely not
an out-of-the-question choice. It's all fine and dandy that your apps
lived nicely with this corruption, and may have even relied on it - the
same exact behavior may have crashed someone else's site. Weighing one
bad option against the other, this option made more sense to us.
If you have to break applications to fix a problem, then you are not
fixing the problem. You are only moving it to your users. What would you
do if PHP was a commercial product like Coldfusion? Do you believe your
customers would be happy with this issue if they had a *major*
enterprise level application that now spewed out nonsensical errors into
their log files? Do you think they would be happy with having to spend
more time and money to fix a problem that wasn't a problem before?
The impression that a lot of people are getting is that the PHP
developers took the quick and easy route for fixing the bug, instead of
actually fixing it, and it scares them. Rightly so as well. Is this
going to become a regular occurance? How often are we going to be told
that the programming methods we have been using for years are wrong and
break the engine? As someone else said in this thread
http://www.sitepoint.com/forums/showthread.php?t=290808:
What else is waiting in the wings? Am I going to have to do this right
now...
PHP Code:
$text = "Hello";
print $text;
...for when they "fix" the next memory leak in three years time?
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
