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…
Things you should know about PHP 7
51–60 of 124 posts
Re: Things you should know about PHP 7
#52Seeing 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.
Everything old is new again.
Re: Things you should know about PHP 7
#53Seeing 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.
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
#54EDIT: fixed some spelling errors
Re: Things you should know about PHP 7
#55Scalar 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
#56While 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.
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
#57Earlier 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 :(
I haven't benchmarked either though.
Re: Things you should know about PHP 7
#58question. 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
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
#59Earlier 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.