Things you should know about PHP 7

> 1. Scheduled to come out in Q4 2015

Which won't happen, I can tell you. PHP's release dates always slip by at least a month, and that's without a very unstable master branch like PHP 7 has.

If it does happen, it'll take a few micro (7.0.x) releases until it reaches stability.

> 3. Return Type Declarations & Scalar Type Hints

Also strict scalar typing:

  <?php
  declare(strict_types=1);
  sin(false); // error
  strlen(2); // error

However, Zend not mentioning this is to be expected. The company's founders (Zeev Suraski, Andi Gutmans) and employees (Dmitry Stogov and some others) are some of the biggest opponents of strict typing in PHP.

-- disclaimer: I am a former PHP internals developer

> 1. Scheduled to come out in Q4 2015

... and available on general cheap webhosting sometime around 2020. If we're lucky.

Thank god our company slowly moved away from building small PHP websites that have to run on the most fucked up PHP installations from the before-time. Now it's PHP 5.6+ everywhere :-)

Thank you. This website is completely useless on mobile.

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.

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

...Abstract syntax tree? I didn't know it was implemented without using AST. It surprises me, as I've been always told that ASTs are necessary to implement a compiler. Maybe there seem to be some alternatives?

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 on top of the framework, I have no idea. Being a generic CMS, I presume their abstractions are a little bit overengineered.

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.

I'm sure D8 is a lot slower--isn't performance usually the last thing worked before release?--but I don't think D7 has really been distinguished by its speed either. In my experience, D7 speed tuning consists almost entirely of inserting and tuning cache layers at every level. In other words, working around the slowness of the application.

Drupal seems great for a content-heavy site that caches well. Personally, I would not build an account-based, heavily personalized web app in Drupal unless I knew the audience was pretty small.

Even in the dinky D7 sites I've run, we got significant performance improvements just by handing off search and commenting to services other than Drupal (SOLR and Disqus).

If you consider bolting on whatever feature the php developers can wrap their heads half way around, as "improving", then sure..

See this reddit comment,

http://www.reddit.com/r/PHP/comments/2zhg6z/how_true_is_this...

and tell me what you think about it. When stuff like this exist, does it matter if it gets all the shiny new features and speed improvements? Not to mention that by php's development culture, these new features probably end up half baked and with it's own set of weird behaviors...

Because it hasn't begun speed improvements yet. Basically once everything is "done", everyone will optimise it to run faster.

There are lots of improvements going in to make it 'fast by default'.

I'd say it's to do with having been rebuilt with Symfony components. That's not to say symfony is, by necessity, slow, but I going to guess that completeness and stability was first for such a big change before performance. But... that's just a guess.

> If you did PHP you were sort of in an untouchable uncool class.

That's still around, even on Hacker News. Tons of comments in poor taste from posts about 3 months ago as I remember it

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

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.

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

Email Zend.

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

The idea is that the old php syntax "function foo ()" remains unchanged [1] so developers can keep searching for "function foo". Removing "function" as keyword is a different topic and is discussed in a separate php thread [2].

The thing you mention ("float function add(){}") keeps the option to search for "function add", but I am unsure why this is not taken into account in this proposal.

Anyhow, I am pretty happy this finally made it to the php language.

[1] https://wiki.php.net/rfc/return_types#position_of_type_decla...

[2] http://marc.info/?t=141235344900003&r=1&w=2

Go also does types different from C, and they have a nice page explaining the reasoning of their syntax here: http://blog.golang.org/gos-declaration-syntax

> function add( ... ): float {}

Which if you read it out, it sounds entirely natural "This is a function called foo, which takes some params, and returns a float". Most of the other variants don't read as naturally.

> Since that's how it's done in other languages and people would feel at home with it.

PHP doesn't need to copy the mistakes of other languages. It's got plenty of its own mistakes.

I thought that was rather odd as well. Are there many languages using this form of return type specifier?

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

This is actually how it's done in Pascal.

Everything old is new again.

Swift?

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 and http://parametricity.net/dropbox/yield.subc.pdf )

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.