Live data from Hacker News

Things you should know about PHP 7

pages.zend.com

51–60 of 124 posts

Re: Things you should know about PHP 7

#51
post #8

Good to see PHP slowly improving, although I haven't used it for years now. On a side note, does anyone know why Drupal 8 is apparently so absurdly slow? I know it's not entirely fair to compare against D7 as it's still technically "under development" but it just seems insane to take that much of a performance hit for nicer OOP semantics...

Drupal 8 is being developed in the Symfony framework. You may have been exposed to a deployment running in development mode (app_dev.php in the URL is a good sign even if not a necessity). Once the debug flag is turned off, Symfony won't check the freshness of the dependency container as well as templates, bootstrap caches, etc. (you clear the cache manually in production.) As to what the Drupal devs may have added o…

AFAIK Drupal doesn't use symfony "framework edition" , but symfony/http kernel library at its core to abstract the default PHP http api. So it is a Symfony app as much as Laravel is ... it's not Symfony full stack.

Re: Things you should know about PHP 7

#52

Seeing this: > function add( ... ): float {} I think a much better choice would have been: > float function add( ... ) {} Or just: > float add( ... ) {} Since that's how it's done in other languages and people would feel at home with it.

This is actually how it's done in Pascal.

Everything old is new again.

Re: Things you should know about PHP 7

#53
post #16

Seeing this: > function add( ... ): float {} I think a much better choice would have been: > float function add( ... ) {} Or just: > float add( ... ) {} Since that's how it's done in other languages and people would feel at home with it.

Haxe uses the first syntax, as does AS3. So it's not like "other languages" are universally opposed to this order.

sure but AS3, Go Haxe and others ARE consistant

    function foo(a:int,b:string):bool{}
in PHP this will be

    function foo(int a,string b):bool{}

Re: Things you should know about PHP 7

#54
question. if, given a programming language is Turing Complete, is it possible that we might stop further development on some of the more,,, crappy languages that are already out there and adopt some of the less crappy ones to fill in any feature gap? i'm all for diversity and experimentation, but doesn't evolution say that some things just gotta die?

EDIT: fixed some spelling errors

Re: Things you should know about PHP 7

#55
The spaceship is actually a lot cooler than many PHP devs realize. Rails devs find it extremely handy. Now that my PHP apps are moving away from being big apps that render full web-pages, and towards being a thin application layer that just renders JSON, I'm finding a higher % of my code is just sorting operations. Closure has helped a lot with this, and nearly all my s are almost certainly going to be in the form of `function($a, $b) { return $a->getThingy() $b->getThingy(); }`

Scalar type hints are a bit of a no-brainer. Type-hinting classes is nice, but there's a lot of sloppiness out there because if you can't type hint as a scalar, not only do you need a separate check to see if it's int or string, you also specifically cannot say it's non-object/array in your function declaration. One of the biggest inconsistencies I see, especially on old CMSes, is where you'd have a method in one class like `function doThing(Page $page) {`, and elsewhere as `function differentThing($page) {`, and sometimes differentThing's $page is a Page, other times it's an int with that page's ID or name. Yes there are all kinds of ways to check for that today, but it benefits everyone if the easiest way to do something is also the right way.

Return type declaration has been in Hack for a while, and it's really handy there. Any C or Java programmers know how useful they are. My big hope here is that they encourage others to stop returning mixed-types, which is a pattern that inevitably just puts more control logic around every call to that function. I don't care too much about nullable type-hints on parameters (you can still set a default `= null` to allow nullable), but I'm _really_ hoping the nullable return-types passes. Having worked with this for a while in Hack, return types are far more useful if they're nullable. e.g. you say `function isUserActive(): bool`, that's totally fine since you're clearly expecting it to be true or false, but if you had `function getActiveUser(): User`, you'd want the option to return null if there is no active user, which could be done nicely as `function getActiveUser(): ?User` if this passes: https://wiki.php.net/rfc/nullable_types#return_types

Now that we're finally actually making a proper PHP spec, I'm not as excited about 4 and 5 as they'd like us to be. It's definitely faster, but if the Zend engine isn't the only game in town, it doesn't matter as much. All the HHVM benchmarks I've seen still put it way above PHP7.

Re: Things you should know about PHP 7

#56
post #38

While I eagerly look forward to PHP7, you can get more than PHP7 speed now with HHVM, and HHVM has never been easier to use. But competition is good, great actually. HHVM recently folded in JIT regex like PHP7, so they are copying from each other.

Hack is also a substantially better language than PHP.

It, directly or indirectly, fixes a lot of horrible behaviour. PHP's absurd comparison operators, for instance, are safely usable once you drop them into a statically typed environment.

Re: Things you should know about PHP 7

#57
post #23

Earlier quoted context omitted.

Well, maybe you should review your stack. Which C extensions are you missing? There are alternatives for the most part (barring GUI)

The ones I miss most frequently are a faster json parser (I use ujson), a faster msgpack parser and a faster database driver. The pure python versions (even on PyPy) don't make the cut :(

Are you not able to use C extensions for some reason? Both the stdlib json module and the msgpack-python implementation have C acceleration modules (with pure Python as a fallback).

I haven't benchmarked either though.

Re: Things you should know about PHP 7

#58

question. if, given a programming language is Turing Complete, is it possible that we might stop further development on some of the more,,, crappy languages that are already out there and adopt some of the less crappy ones to fill in any feature gap? i'm all for diversity and experimentation, but doesn't evolution say that some things just gotta die? EDIT: fixed some spelling errors

People do already choose languages other than PHP because they find PHP crappy. But in evolutionary terms, clearly PHP (and by extension Hack) are evolving, and are successful in their niche. If you don't want to use PHP you don't have to, alternatives already exist in abundance - including, of course, the fork of PHP itself. So use Java, or Python, or Ruby or C# or whatever floats your boat.

But if you're arguing that PHP should not be allowed to exist despite there still being a community that uses it and despite there still being improvements made to the language and despite its success, that's not an evolutionary argument, it's an elitist one.

Re: Things you should know about PHP 7

#59
post #57

Earlier quoted context omitted.

The ones I miss most frequently are a faster json parser (I use ujson), a faster msgpack parser and a faster database driver. The pure python versions (even on PyPy) don't make the cut :(

Are you not able to use C extensions for some reason? Both the stdlib json module and the msgpack-python implementation have C acceleration modules (with pure Python as a fallback). I haven't benchmarked either though.

That's my point, I can't use the extensions with pypy. And this stuff is usually the bottleneck.
Post reply on HN