Comment by nikic | Hacker News Reader

Comment by nikic | Hacker News Reader

For those wondering what the new features for PHP 5.5 are at this point, here is a small (not complete) list:

Large language changes:

* Generators and coroutines (https://wiki.php.net/rfc/generators by me)

* `finally` blocks (https://wiki.php.net/rfc/finally by laruence)

Syntactic sugar:

* Support for function calls in `empty()` (https://wiki.php.net/rfc/empty_isset_exprs by me)

* Support for `list()` in foreach (https://wiki.php.net/rfc/foreachlist by laruence)

* Constant array/string dereferencing (https://wiki.php.net/rfc/constdereference by laruence)

* Getting the fully qualified class name using `ClassName::class` (https://wiki.php.net/rfc/class_name_scalars by ralph)

Standard library:

* Simplified password hashing API (https://wiki.php.net/rfc/password_hash by ircmaxell)

* `hash_pbkdf2()` function (https://wiki.php.net/rfc/hash_pbkdf2 by ircmaxell)

* DateTimeImmutable, which is an immutable variant of DateTime (by derick)

Key anti-features (aka BC breaks):

* Dropped Windows XP and 2003 support (by pierre)

* ext/mysql deprecated (https://wiki.php.net/rfc/mysql_deprecation by aharvey)

* preg_replace /e modifier deprecated (https://wiki.php.net/rfc/remove_preg_replace_eval_modifier by me)

* Logo GUIDs removed (by ajf)

For the beta 1 (the next planned released) at least two more things are planned:

* Bundling of ZendOptimizer+ (https://wiki.php.net/rfc/optimizerplus by zeev)

* Allowing non-scalar Iterator keys in foreach (https://wiki.php.net/rfc/foreach-non-scalar-keys by me)

I feel like there are dark factors at play for dropping the XP support. Although the most thorough discussion of it is at http://programmers.stackexchange.com/questions/177732/why-wa..., the conspiracist in me says that Microsoft (pierre's employer) pressured him to drop support - even though it wasn't entirely necessary to do so.

That's a good catch, and the justification was a little soft. But would you blame them?

Frankly, I'm irritated at them for dragging their heals on getting the PECL4Win back up and running (and the lack of updates to http://downloads.php.net/pierre/ doesn't help matters.)

Since I've moved to the camp of "You developing PHP and use Windows? Let me show you how to setup Vagrant" I've become less concerned about the state of PHP & Windows. I just won't tolerate when people say PHP dropping XP support is a good thing (which the OP wasn't saying, but some have.)

DLLs for PECL exts are currently available here: http://windows.php.net/downloads/pecl/ Not for all of them, but some of the more important ones. If you want something added to the list it's usually as simple as pinging Pierre on IRC :)

Someone should update the "In the meantime, some extensions can be found here." link on http://windows.php.net/, then.

The answers in that thread seem to be reasonable. XP is a decade-old OS, we should be glad that it will finally pass on April 2014. Supporting multiple operating systems takes time, especially for one that old. At some point it's best to move on.

If your company is affected by lack of XP support in this PHP build, it should be a temporary convenience at worst. What are your plans to migrate off XP over the next year? As of next April there will be no patches or security fixes coming for XP. Is your company planning on paying Microsoft for continued support, or will it negotiate extended XP support in return for buying company-wide Windows 8 licenses and start the ride over again?

I suspect that many of the people using XP today are frozen and wouldn't upgrade their PHP anyway, for the same reasons they're using XP and IE6. They either don't want to change their software because of cost/risk issues or the people who wrote it moved on years ago and they have no idea how it works.

I think you're right about the reasons for not upgrading. For orgs still using IE6 and XP, statistically it's very likely they're not going to be doing new development in PHP 5.5. (statistics pulled from thin air based on 15 years of experience with PHP and orbs who use it).

There's not been any security patches for PHP 4 for many years, but people still use it. Those same sorts of orgs will continue to use stuff out of date and unsupported for any number of reasons. Catering development processes around an increasingly small number of users doesn't make sense.

Regarding XP support; i'm not invested in this discussion, but the code has #defines for NETWARE[1], riscos[2], and even CRAY[3] in it... The last NetWare and RISC OS releases were (surprisingly to me) only 3 years ago, but surely XP is even now a much bigger deployment target? How often does the CRAY code get tested?

1. http://lxr.php.net/search?q=&defs=&refs=NETWARE&...

2. http://lxr.php.net/search?q=__riscos__&defs=&refs=&#...

3. http://lxr.php.net/search?q=CRAY&defs=&refs=&pat...

Are ZendOptimizer and APC meant to cohabitate in the core, or is the former going to replace the later ?

Any news on object literals $o = {'abc': 456}; and scalar type hint ?

Thanks for all the hard work, improvement in the language in 5.3 and 5.4 were awesome.

ZO+ will replace APC, only the user-cache from APC will be left (see also this comment: http://news.ycombinator.com/item?id=5343883).

Object literals and scalar type hints won't be in 5.5. Scalar type hints may be in the next version (it's a rather tricky topic). For object literals I don't see reason to add them at all (in PHP you can just use arrays ^^).

> in PHP you can just use arrays ^^

Which thankfully aren't as painful now!

    $cfg = [
        'path' => '.',
        'mask' => 655
    ];

Otherwise, if we still had to write "array" each time, I'd be more supportive of the object-literal, although I do think there's value in the literal but mostly to make the language similar to other languages with similar constructs (js, py).

With arrays you would have to do:

    $o = (object)[
        'foo' => 'bar'
    ];

Personally I think there should be a way to create objects right away instead of having to cast an array. Maybe there is a good reason all together for not using objects but I very much prefer typing $var->field instead of $var['field'].

Sure, but this still doesn't work:

  $o = (object)[
      'foo' => function(){ print 'bar'; },
  ];
  $o->foo();

You have to do it this way:

  call_user_func($o->foo);

Or this way:

  $foo = $o->foo;
  $foo();

Which doesn't work when foo is defined as a class method.

I believe by design it will always be: $foo = $o->foo; $foo();

Using __get/__set behaves the same way. Let's say $o is of SomeType that defines those magic methods. You can have a function foo on that type that is defined as a public method.

    $o->foo(); // the actual instance method
    $o->foo = function() { print 'bar'; };
    $o->foo(); // same instance method
    $foo = $o->foo;
    $foo(); // prints bar

In the case of StdClass it might be possible to do it your way where foo could be callable ($o->foo()) but I can see why they wouldn't allow this in order to keep things consistent.

Edit: It also behaves the same way if you assign a function to a public field of a class (I'm using 5.4) so I actually support not allowing a method to be directly callable in this fashion because this would be the only case where this behavior would occur.

Frankly, it would be infinitely better to be able to write:

    $data = {
        firstName: "John",
        lastName: "Smith",
        age: 25,
        address: {
            streetAddress: "21 2nd Street",
            city: "New York",
            state: "NY",
            postalCode: 10021
        },
        phoneNumber: {
            home: {
                number: "212 555-1234"
            },
            fax: {
                number: "646 555-4567"
            }
        }
    };

Rather than the awkward and verbose:

    $data = (object) [
        "firstName" => "John",
        "lastName" => "Smith",
        "age" => 25,
        "address" => (object) [
            "streetAddress" => "21 2nd Street",
            "city" => "New York",
            "state" => "NY",
            "postalCode" => 10021
        ],
        "phoneNumber": (object) [
            "home" => (object) [
                "number" => "212 555-1234"
            ],
            "fax" => (object) [
                "number" => "646 555-4567"
            ]
        ]
    ];

JSON is everywhere these days, supporting object literals is a very, very big deal; I understand which features to implement are handpicked very carefully so as not to clutter more the core, but we are talking about making the life of devs who use and write JSON more difficult, and that happens to be lots of folks.

Telling people to use arrays and be done with it is the equivalent of implement a strpos function that may only accept a string that's 5 characters long — yes, theoretically you can work with that splitting your strings, but that's time consuming and a inconsistent behaviour (why would 10 character long strings be less of a citizen than 5 char long ones?)

JSON, JavaScript Object Notation. How does it make sense to write PHP in Javascript syntax, when PHP has its own defined syntax?

Because 1) PHP syntax for object literals is non-existent 2) JSON is used in many more places than just Javascript and 3) the syntax of JSON makes sense; it's compact, human readable and easy to write. I'm not suggesting copying it 1:1 verbatim, but something close to JSON would definitely be an improvement. See for example how MongoDB uses a JSON-like syntax to great effect.

If for no other reason than ':' is easier to type than '=>'?

Hell will surely descend upon me, but I'd vote for having it be syntactic sugar for => in general.

You can already use the js-style shorthand inside of Twig templates, and I've been caught absentmindedly forgetting to switch to the 'proper' way for raw php now and then. And I would like to never need to even touch the shift key when having to write out an array or an object but even JSON won't let you do that. It's a step in the right direction, though.

Hey, great work on that generators patch! Very well documented. It's been years since I wrote PHP but it's nice to know that if I have to at some point I'll have some things I like from Python and other languages available to me now.

Good stuff nikita, keep up the great work. I also vote for getting object literals added (it will be a great addition to the array literals).

Reply on news.ycombinator.com