Some of the painting is new, but the engine (stdlib) remains the same.
Also PHP could easily add sane new stdlib if it wanted to, and keep supporting the old one as long as people want to. I just don't think anyone is really interested in doing so. Most PHP users don't care much, and few large companies that fund the work are mainly focused on keeping the ship from sinking.
They care. They are interested.
But backwards compatibility is a huge issue. PHP7 is much better, it's faster, it uses less resources, and yet you still have hosts running PHP 5.3, some even running 5.2! How do you combat a crowd like that? I don't want PHP to get stuck in IE6 mode, and I sure hope the community voices their valid criticism and takes action.
Have they really been, PHP issues would be fixed long time ago. It had 7 major releases, and people complain about exactly the same things. All the people I know who complain about it and switch to something else say the exact same things, no matter what PHP version they've left behind. Those who do care simply go somewhere else, only those who do not or have massive codebase to support stay.
> PHP7 is much better
Lets agree to disagree on that. Its not better enough to draw any of PHP opponents to it.
> you still have hosts running PHP 5.3, some even running 5.2! How do you combat a crowd like that?
You don't. Let them be. There are people using PHP 1,2,3 and 4 somewhere out there. They may never switch. Why should it hold back the rest of the world?
> I don't want PHP to get stuck in IE6 mode
The whole PHP is its own IE6.
Come on, if a handful inconsistent function names is all the problem with PHP to you, let me suggest you to get yourself a good IDE with a code completion feature. You'll forget that "broken stdlib" forever... of course if your aim is to get the job jone, not to slander a language you aren't working with.
set_error_handler("myErrorHandler"); function myErrorHandler($errno, $errstr, $errfile, $errline) { throw new Exception($errstr, $errno); }
Is all you need.
They are functions - yes. If your first language was fully OOP, then probably PHP is not your language of choice. It doesn't make it bad, though.
So you think boxing all kinds of errors into one generic exception type is a solution to this shortcoming of the language?
That sure feels like a 'php' solution. I will give you that. But that ain't pretty (even as a work around), and no, it does not do the job. May be if you don't know how to work with exceptions in the first place, then it might work for you. But you might end up with a code base like this [1]
[1] http://stackoverflow.com/questions/3425835/converting-errors...
Instead you started nitpicking on the solution. That's dishonest. And it makes the discussion endless.
> Third, nobody does it.
This statement of yours clearly states that you have no idea of the actual PHP ecosystem. Every single major PHP framework is routinely doing it.
So the choice is between insane behaviour, or breaking the code.
> Instead you started nitpicking on the solution. That's dishonest. And it makes the discussion endless.
Because the problem is unsolvable. You cannot get PHP to behave sanely unless you redo everything it does. If you fix one thing, dozens of other will fall apart.
>Every single major PHP framework is routinely doing it.
Right, I wasn't aware of this. How do you write libraries for PHP than, you choose between using what's in stdlib as it is and being used within a framework where exceptions are thrown? Support both? Ignore the problem? Or every library makes its own choice how stdlib should behave? Do the frameworks convert strerr and errno into something usable?
Welcome to PHP 7
I don't know about OP. But it is not just that. Php is a flawed language to its roots. Just think of the community that has tolerated a feature like register_globals for, I don't know, 15 years?
What good can you expect from it?
Also, that was not the question, at all.