Hacker News new | past | comments | ask | show | jobs | submit login

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




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.


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




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: