Amusingly, after months of pointless bikeshedding, we managed to convince the internals team to throw an exception during the extreme case of a CSPRNG failure.

https://www.sammyk.me/security-changes-to-the-php-7-csprng-i...

You can read my arguments on the mailing list, but basically it amounted to:

    $chars = 'abcdefghijklmnopqrstuvwxyz234567';
    for ($i = 0; $i < 12; ++$i) {
        $password .= $chars[random_int(0, 31)];
    }

If random_int() returned FALSE, $password would be the string 'aaaaaaaaaaaa' (and you'd have 12 E_WARNING errors in your log).

By making it an exception, random_int() will now fail closed (kill the script by default), but the developer can still handle it gracefully.

    $chars = 'abcdefghijklmnopqrstuvwxyz234567';
    try {
        for ($i = 0; $i < 12; ++$i) {
            $password .= $chars[random_int(0, 31)];   
        }
    } catch (Throwable $e) {
        $framework->template->kill('An unrecoverable fatal error occurred.');
    }

Or something similar.

Is it a BC break? Sure. Is it worth it? Oh yeah.

We need more BC breaks, not fewer. I'd really like to see a lot of functions that return FALSE on failure throw exceptions in the future. We could also tidy up the stdlib a bit and give primatives some OO love.

If you're going to break BC, might as well do it right.

So, onwards to PHP (gr)8?

I'm hoping Hack can liberate us.

Wow this thread reeks of negativity

It's a thread about PHP on Hacker News. Even if there were no comments at all it would still reek of negativity.

Honestly I'm amazed that even here on hackernews PHP gets so much hating over meaningless things.

I mean, hating PHP for copying Java OO model in 2004? Com'on... It's not like PHP ever wanted to be a fancy language.

EDIT: Apparently PHP5 was released in 2004, not 2003.

EDIT2: One thing PHP got right over Java: type-hinted parameters are not nullable by default. NullPointerException anyone?

Why does everything start with a backlash? I do not get this language at all.

The namespace separator in PHP is \. It seems like a horrible idea at first, but in practice the only place you ever see it is at the top of files:

    use Psr\Log\NullLogger;
    use Psr\Log\LoggerInterface;
    use Psr\Log\LogLevel;

…and then the rest of the code just uses NullLogger, LoggerInterface and LogLevel.

I just don't get why, of all the OO systems out there to inspire an engineer, the PHP people picked Java.

PHP is much more of a static language than a dynamic one. Therefore it has more in common with Java/C++ than with Python, Ruby, or JavaScript. It's also a very pragmatic choice for an OO system.

You could say that PHP == "static language", even if you maybe can't say PHP === "static language"?

That's a disturbingly clever way of putting it. :)

PHP wasn't always what it is now, that's OPs point. They are where they chose to go. Probably in the search of legitimacy, they chose to follow the most enterprisey language.

But you, like the OP, fail to communicate exactly WHY this is a bad thing. You just take it for granted that your point stands on its own without an explanation.

Why NOT Java?

Java is a fairly ugly OO system, basically. It's purely my opinion, of course, but not an uncommon one.

Since I don't have to use PHP I'm not too upset. I was really just lamenting the state of the world.

Same thing as before, you've stated it's ugly, but haven't given any specific examples of why you think this.

do we really need to see bad java examples to understand his opinion?

Just because a language is used to write bad code doesn't mean the language design itself is bad.

Exactly. I've seen beautifully written Java and I've seen (and written) ugly Java. The language syntax is by far the least contributing factor to the 'prettiness' of the code. With the exception of BF. :)

Yes. Just some general points or examples.

I personally feel like PHP OOP is much more like C++. It's just not surprising that two high-level languages based on C++ end up near the same place.

PHP is heavily based on C so choosing to make it's OOP features like C++ isn't a big leap.

Plus PHP is still far less enterprisey than Java so maybe the OO model isn't the real issue.

Yeah I really miss the good old days of PHP3.

/s

Zend has made a lot of good decisions (and a few painful but livable bad ones) over the last decade.

Indeed, a few years ago Paul Biggar (CircleCI) tried to compile PHP extensively and said it was far too dynamic to do "good" compilation (I'm distorting his words a lot here).

Because it was familiar to them and they didn't bother to research more. That applies to a lot of decisions the PHP folks have made in the past.

Who knows, perhaps it's one of the biggest reasons they're so successful, however much we who know better dislike that.

It has been picked for a long time now, so it is hard to put yourself in the heads of the designers at that time. Having said that, PHP OO (like C#, ActionScript, etc at that time) was probably inspired by Java for pragmatic reasons.

Out of curiosity, why does PHP use backslashes in throwable names?

The backslash is the namespace separator. This just indicates that these classes are in the root namespace. This is the same as prefixing :: in front of C++ class names.

This is the official explanation as to why the delimiter is a backslash - https://wiki.php.net/rfc/namespaceseparator

To this day, the table on that page remains one of my favourite examples of PHP's badly thought out design.

PHPs design and grammar precluded using any of the other existing operators. The backslash is really the best choice and in practice it works pretty well. The actual debate on the separator choice was very very very long.

Yeah, and also: Who gives a shit? It's the convention they chose, just adapt to it and get over it, or program in a different language.

People who like to complain about PHP are rarely the same people who use it every day.

I have to use PHP every day and I rarely go a day without complaining about it.

You're the exception, not the rule.

I mostly hear C/C++, Ruby, Python, etc. devs complain about PHP. Very rarely actual PHP developers.

And typically, their complaints are less of the moan-ass "waaah, they use a \ for namespace separation" and more "ugh, why don't they disabled emulated prepared statements by default"?

Only one side is constructive.

None of those who are complaining about the monument of shit being erected outside of town is actually an erector of monuments made of shit.

Typically, their complaints are about the ugly appearance and smell.

Only one side is constructive.

I still don't get what stopped them from using any of the existing operators.

Rationale was discussed on IRC, see:

https://wiki.php.net/_media/rfc/php.ns.txt

Linked to at the bottom of:

https://wiki.php.net/rfc/namespaceseparator

I skimmed through it but couldn't really understand why they couldn't coopt one of the existing operators (for example, by making classes have a namespace for their methods)

Couldn't they provide a clearer explanation than simply dumping a huge IRC log like that??

Basically namespaces operate at a different level. You can almost imagine it like Macro expansion -- the namespaces are fully resolved for all the symbols in the file and then the compilation happens. This is necessary for a host of reasons. They can't co-opt an existing operator because all the existing operators work at an entirely different level.

The reality is that the parser is absolute shit and that sort of necessitated the character not being '.'

But you get used to that kind of stuff writing PHP. At least Facebook is making things better.

I'm 99% sure this isn't satire.

Heh, I was wondering the same. As others have pointed out, it looks like it's the namespace separator. Now someone has to explain why on Earth you need the namespace separator if these class names are already in the namespace?

PHP has an incredible knack for almost copying other languages' features, but making them uglier in some random way, for no particular added benefit.

(I know, I'm a hater... but seriously, why?)

> Now someone has to explain why on Earth you need the namespace separator if these class names are already in the namespace?

You don't. This is just illustrating these classes are in the global namespace.

> PHP has an incredible knack for almost copying other languages' features, but making them uglier in some random way, for no particular added benefit.

Well you have a case for "no added benefit" typically they aren't ugly for a random reason. There's a lot of very necessary reasons for the way these things work while making a language which is still PHP. PHP isn't precompiled. PHP has autoloading of classes. PHP allows code to be imported into other code. Combining namespaces with all the other existing features isn't an easy task.

if you do not include the namespace separator, and you import a namespace with the same name defined, you'll have a not-so-pleasant surprise. e.g.:you use "Exception" to catch all exceptions, and someone defines "SQL\Exception", then you import "SQL", and now all your catch blocks stop working. But don't worry. This is business as usual in the PHP world.

The namespace separator is not required if already in the correct scope. I am not sure why the author decided to include them in the examples.

Modern PHP code rarely uses the global namespace, so almost everyone who cares about correct handling of the new exceptions will have to prefix them with a backslash anyway.

Both the LogicException and the RuntimeException branches seem kind of pointless... They all describe exceptions that happen with values at runtime and I expect I'd have trouble picking one in a given circumstance. Mostly I see it leading to a lot of inconsistent uses in practice. At least 4 of them would be legitimate choices for a string thats too short, for example.

Ah, PHP.

The logic behind the difference is in the fact that PHP doesn't have assertions - the naming is based on the root cause, not when the occur.

A RuntimeException is something like "Database connection failed." A LogicException is an implementation issue (e.g. usually requires a code change to fix).