3 ms·
ZO+ will replace APC, only the user-cache from APC will be left (see also this comment: http://news.ycombinator.com/item?id=5343883 http://news.ycombinator.com/
by nikic 14y ago
ZO+ will replace APC, only the user-cache from APC will be left (see also this comment: http://news.ycombinator.com/item?id=5343883 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 ^^).
- k3n 14y ago> 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).
- yogo 14y agoWith 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'].
- brokenparser 14y agoSure, 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.
- yogo 14y agoI 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.
- Mahn 14y agoFrankly, 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?)
- Jeremy1026 14y agoJSON, JavaScript Object Notation. How does it make sense to write PHP in Javascript syntax, when PHP has its own defined syntax?
- Mahn 14y agoBecause 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.