Live data from Hacker News

An Exceptional Change in PHP 7.0

daveyshafik.com

41–50 of 53 posts

Re: An Exceptional Change in PHP 7.0

#41

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

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.

Re: An Exceptional Change in PHP 7.0

#42

Earlier quoted context omitted.

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.

Re: An Exceptional Change in PHP 7.0

#43

Earlier quoted context omitted.

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.

Re: An Exceptional Change in PHP 7.0

#44
post #38

Earlier quoted context omitted.

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.

Re: An Exceptional Change in PHP 7.0

#45
post #25
post #6

Earlier quoted context omitted.

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. :)

Re: An Exceptional Change in PHP 7.0

#46
post #17

Earlier quoted context omitted.

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?…

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.

Re: An Exceptional Change in PHP 7.0

#47

Earlier quoted context omitted.

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.

You hear real engineers with actual experience in other languages complain about the two clawed hammer of languages. It's because there isn't a stockholm syndrome when you know something other than PHP. PHP is a mess, it's a hugely popular mess in the same way that a McDonald's hamburger is a hugely popular mess. If you ask someone about their favorite burger or language, you'll rarely hear that McDonald's or PHP is on the tip of someone's tongue. If you ask someone why they ate at McDonald's or why they used PHP, you'll likely hear some bullshit justification that amounts to "it was there when I needed it." Fuck PHP.

Re: An Exceptional Change in PHP 7.0

#48

Earlier quoted context omitted.

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.

If you use PHP every day, you know nothing outside your slum. PHP started as a crappy Perl and evolved into a terrible Perl with the worst of Java bolted on after the fact. It's not a good language. I occasionally have to hold my nose and sling some PHP and I think it's the worst thing possible, bar none. What would you think is a worse alternative to PHP within the realm of dynamic languages? PHP fosters a culture of being proud of knowing no better way and not complaining about the shit you have to trudge through to do basic programming tasks.

Re: An Exceptional Change in PHP 7.0

#49

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 If random_int() returned FALSE, $password would be the str…

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.

Re: An Exceptional Change in PHP 7.0

#50
post #49

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 If random_int() returned FALSE, $password would be the str…

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?
Post reply on HN