
Things you should know about PHP 7 - speg
https://pages.zend.com/TY-Infographic.html
======
babuskov
TL;DR:

1\. Scheduled to come out in Q4 2015

2\. <=> operator, see [https://wiki.php.net/rfc/combined-comparison-
operator](https://wiki.php.net/rfc/combined-comparison-operator)

3\. Return Type Declarations & Scalar Type Hints

4\. Speed improvements (25-70%)

5\. Yep, speed improvements are for real.

You're welcome.

~~~
raphaelj
So 1 is not a feature, 4 & 5 are the same thing (and maybe a consequence of 3)
while 2 can be remplaced by a single function.

Seems like the only new feature are type hints. Looks like Hack has been
rebranded as PHP 7.

~~~
wvenable
There are tons of new features, this list is pretty pathetic. I'm not sure why
the spaceship operator got top billing when there has been so many other great
changes.

~~~
TazeTSchnitzel
Because it has a cool name.

------
itafroma
Note this is just Zend's take on what's important in PHP 7: it's not a
complete list.

A more comprehensive list:

\- Dual-mode scalar type hints (weak by default, toggleable to strict via a
per-file syntax)
([https://wiki.php.net/rfc/scalar_type_hints_v5](https://wiki.php.net/rfc/scalar_type_hints_v5))

\- Return type declarations
([https://wiki.php.net/rfc/return_types](https://wiki.php.net/rfc/return_types))

\- <=> operator ([https://wiki.php.net/rfc/combined-comparison-
operator](https://wiki.php.net/rfc/combined-comparison-operator))

\- Null coalesce operator (??)
([https://wiki.php.net/rfc/isset_ternary](https://wiki.php.net/rfc/isset_ternary))

\- Closure::call
([https://wiki.php.net/rfc/closure_apply](https://wiki.php.net/rfc/closure_apply))

\- Abstract syntax tree
([https://wiki.php.net/rfc/abstract_syntax_tree](https://wiki.php.net/rfc/abstract_syntax_tree))

\- Context sensitive lexer, allowing the use of reserved words in more places
([https://wiki.php.net/rfc/context_sensitive_lexer](https://wiki.php.net/rfc/context_sensitive_lexer))

\- Unicode escape syntax in strings
([https://wiki.php.net/rfc/unicode_escape](https://wiki.php.net/rfc/unicode_escape))

\- A uniform variable syntax
([https://wiki.php.net/rfc/uniform_variable_syntax](https://wiki.php.net/rfc/uniform_variable_syntax))

\- Expectations
([https://wiki.php.net/rfc/expectations](https://wiki.php.net/rfc/expectations))

\- Use declaration grouping
([https://wiki.php.net/rfc/group_use_declarations](https://wiki.php.net/rfc/group_use_declarations))

\- Removal of a ton of long-deprecated features

\- Massive speed improvements

You can see everything that's been added to PHP 7 on
[https://wiki.php.net/rfc](https://wiki.php.net/rfc) (look under Accepted and
Implemented - PHP 7.0)

~~~
arenaninja
OH man I want that Null coalesce operator so bad...

~~~
smutticus
I feel like I've needed that since I first started coding PHP 17 years ago!

~~~
AlyssaRowan
I feel like I want to test what happens if you put values like "", false, " ",
0, an empty array, etc etc etc in front of ??.

Because, you know, this is PHP.

~~~
itafroma
> I feel like I want to test what happens if you put values like "", false, "
> ", 0, an empty array, etc etc etc in front of ??.

All of those would result in the variable being assigned those values: the
null check uses the same semantics as is_null(), and the truth table for those
values is:

    
    
        $v     is_null($v)
        ------------------
        ''     FALSE
        false  FALSE
        ' '    FALSE
        0      FALSE
        []     FALSE
    

If you want to all falsy values to use the fallback value, use the shorthand
ternary operator (?:) instead.

------
richthegeek
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...

~~~
jkoudys
D8's a work in progress, and if there's one thing I wouldn't be too critical
of a wip for, it's performance.

Frankly I don't really see drupal's place in the world anymore. It's so
absurdly config-heavy, which may have made sense a decade ago but not now.
Everyone will just install composer, put laravel/symfony on there, and be off
to the races. The era of giant pages of drupal-managed plugins is over, and
replaced by package managers + slimmer CMSes like joomla or concrete5.

~~~
snuxoll
Drupal 8 actually using a lot of Symfony2 components internally now, and you
should be able to manage your modules with composer if you so choose.

I'm really excited for D8, no other CMS to date has been as easy to administer
in my eyes, and now that they're dramatically revamping the module and theming
stories I may even enjoy writing modules and themes once more.

~~~
jkoudys
I know, and I think they're making the right decisions to make it the best
drupal it can be. I was really excited about it 2.5 years ago.

My point is I think the fundamental idea of drupal is obsolete. If it can eke
out a few more years of relevance and take market share away from WordPress,
all the more power to them,

------
darrelld
Being a PHP dev since the early 00's it's great to see the language moving
forward with features and performance and seemingly less hate towards it from
the developer community at large. For a while there seemed to be a "PHP-
shaming" thing going around. If you did PHP you were sort of in an untouchable
uncool class.

~~~
teh_klev
Meh...PHP devs think they've got bad here?

I still have to knock out Classic ASP now and again. My dad found out and
won't even look at me or answer the phone :)

~~~
haroldp
I know that pain

------
ck2
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.

~~~
implicit
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.

~~~
TazeTSchnitzel
Hack is merely PHP with poorly-enforced type hints

Unlike PHP, Hack lets you, nay, encourages you, to turn off type checking in
places

~~~
chupy
I don't believe it's just that. One of the coolest features which if it is
used properly actually speeds up the response times of a normal blocking php
script /app flow is the as async feature:
[http://docs.hhvm.com/manual/en/hack.async.php](http://docs.hhvm.com/manual/en/hack.async.php).

------
jkoudys
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](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.

~~~
TazeTSchnitzel
> 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.

I was the only person who seemed to care much about the spec, and I quit. The
spec has several broken tests, numerous omissions and inaccuracies, and
doesn't mention any of the really important PHP 7 features.

I'm not too optimistic.

~~~
jkoudys
All true, but practically speaking I don't know how complete the spec needs to
be. Looking at the HHVM project, they fail a lot of the basic PHP unit tests,
yet also have 100% parity with nearly every major CMS/framework there is. PHP
is just old, and as gone without a spec so long that there's a whole pile of
code that nobody ever touches anymore. Simply implementing a subset of the
spec, like HHVM has, is really all I need.

------
mischanix
There are credentials for the HTTP Auth on a staging environment commented out
in the source of this webpage (Line 317).

~~~
TazeTSchnitzel
Email Zend.

~~~
mischanix
I looked around and couldn't find an appropriate e-mail address anywhere. If
you have one, feel free to let them know.

~~~
TazeTSchnitzel
[https://gwhois.org/zend.com](https://gwhois.org/zend.com)

------
arthursilva
Heck, I'm kinda felling bad as a Pythonista. We're lagging badly speed wise.

Sure, there's PyPy but it's not compatible with the mainstream C-Extensions so
pretty much a no-go for most of my projects. Hopefully Piston will come to
rescue in the future.

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

~~~
arthursilva
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 :(

~~~
kilink
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.

~~~
arthursilva
That's my point, I can't use the extensions with pypy. And this stuff is
usually the bottleneck.

------
franciscop
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.

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

~~~
tne
AFAICT both Haxe and AS3 consistently put types on the right, including
argument declarations. Other languages consistently put it on the left. Most
languages make a choice like that; PHP mixes things up a bit.

But then, it wouldn't be PHP if it was too consistent ;).

~~~
TazeTSchnitzel
To be fair, it's not the same as an argument type. The type of `foo()` isn't
_int_ , it's _function_. You're not specifying the type of the thing itself,
merely the type of what it returns. Though this seems to have been lost on the
creators of C. ;)

------
brianpgordon
This chart can't be right. It takes 12.6 seconds to render the Wordpress home
page?

[http://i.imgur.com/k6Bq9Yz.png](http://i.imgur.com/k6Bq9Yz.png)

------
10098
> Return Type Declarations & Scalar Type Hints

Finally, this took them a long freaking time.

~~~
chriswarbo
Disclaimer: I use the word "type" in the following to refer to types, tags and
classes, because I'm feeling lazy ;)

> Return Type Declarations & Scalar Type Hints

This seems a shame.

We can only add type hints to arguments and return types if we're writing
arguments and return values, which is unnecessarily verbose. We should really
add these types to the functions themselves. For example:

    
    
        $dbl    = function(int $x) : int { return  2 * $x;        };
        $neg    = function(int $x) : int { return -1 * $x;        };
    

We've given types to the inputs and outputs, but the functions themselves
still just have the type 'Closure'; there's no indication about what they
accept or return. Functions are meant to abstract, but this implementation of
type hinting forces us to go and read the implementation!

For example, if we've written the following and we want to add types (where
I've put "???"), we need to look at the implementations of $dbl and $neg:

    
    
        $dblneg = function(??? $x) : ??? { return $dbl($neg($x)); };
    

We could implement the same functions in a different way:

    
    
        $mult = function(int $x) : Closure {
                  return function(int $y) : int use ($x) {
                    return $x * $y;
                  };
                };
        $dbl  = $mult(2);
        $neg  = $mult(-1);
    

Now if we want to add types to $dblneg, the implementations of $dbl and $neg
don't help; we have to dig even further and read the implementation of $mult.

All of this would go away if we could hint the _function_ instead, eg.

    
    
        $mult = function($x) : Closure(int, Closure(int, int)) {
                  return function($y) use ($x) : Closure(int, int) {
                    return $x + $y;
                  };
                };
        $dbl = $mult(2);
        $neg = $mult(-1);
    

Here I've used the ": ???" syntax to hint _the whole function_ rather than
just its return value, and I've written "Closure(x, y)" to mean a function
type from argument type "x" to return type "y". This means if we have a
function, like $dbl, we can query its type in the usual way (`typeof $dbl`)
and get the argument and return types without having to read any source.

Note that this _doesn 't_ require generics/parametric-polymorphism, since all
of the types I've used are concrete. However, adding that would be the next
logical step ;)

Note that we can trivially extend this scheme to functions with multiple
arguments, in all of the various, incompatible ways PHP lets us define them:

    
    
        function add($x, $y) : Closure(int, int, int) {
          return $x + $y;
        }
    
        $add = function($x, $y) : Closure(int, int, int) {
          return $x + $y;
        };
    
        static function add($x, $y) : Closure(int, int, int) {
          return $x + $y;
        }
    
        public function add($y) : Closure(int, int, int) {
          $this + $y;
        }
    
        function add($x) : Closure(int, Closure(int, int)) {
          return function($y) use ($x) : Closure(int, int) {
            return $x + $y;
          };
        }
    
        function add($args) : Closure(array(int, int), int) {
          return $args[0] + $args[1];
        }
    
        $add = function($args) : Closure(array(int, int), int) {
          return $args[0] + $args[1];
        }
    
        static function add($x) : Closure(int, Closure(int, int)) {
          return function($y) use ($x) : Closure(int, int) {
            return $x + $y;
          };
        }
    
        function add() : Closure(int, int, int) {
          return func_get_args()[0] + func_get_args()[1];
        }
    
        function add() : Closure(array(int, int), int) {
          return func_get_args()[0][0] + func_get_args()[0][1];
        }
    
        // and so on
    

This seems to me like another case of PHP ignoring decades of programming
language research and development and instead just "doing it like <popular
language from the 1970s> does it". It's like generators all over again :( (eg.
see
[http://okmij.org/ftp/continuations/generators.html](http://okmij.org/ftp/continuations/generators.html)
and
[http://parametricity.net/dropbox/yield.subc.pdf](http://parametricity.net/dropbox/yield.subc.pdf)
)

------
bovermyer
Between PHP 7 and HHVM, and what appears to me to be an increasingly
fragmented community, I decided to jump ship to Ruby on Rails as my
development platform of choice for web apps.

This is not to say that PHP won't work fine for many people; I just don't care
for the (several) directions PHP is going in.

~~~
jtreminio
Not sure what you mean.

I have not detected any fragmentation. In fact, HHVM's speed of development
has been a much needed kick in the pants to PHP.

~~~
bovermyer
The introduction of a language specification by Facebook is great.

The fact that it took over a decade for a language specification to appear is
less so.

PHP-NG/PHP 7's troubled birth, and its contention with HHVM, does not bode
well for PHP's future. I feel like it's going the route of Perl 5/6;Python
2/3.

