Laravel already does alot of this stuff ^^^
What PHP 5.5 might look like
41–50 of 139 posts
Re: What PHP 5.5 might look like
#42Earlier quoted context omitted.
I, for one, never understood why there was no "default" keyword available, but the python example is great as well. About the rest of the article : - the modified empty() is nice, while I still think this function accepts to much thing as empty, or at least should be more flexible. Getter/setter : finally. Now I don't get why there is no readonly keyword which would put the variable as readonly only for the class' ou…
The article clearly states that there are more features like a read-only keyword. https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
That's not what he's referring to. He's specifically referring to a read-only that only affects external classes. So, the object itself could write to that field, but nothing else could.
Re: What PHP 5.5 might look like
#43These sound like useful improvements, especially the new getter/setter syntax and scalar type hinting.
However, what I'd really like to see in next PHP would be the Composer dependency manager bundled in, a bit like Node.js nowadays ships with NPM. This has really brought a new world of cross-project code sharing into PHP:
I wrote a blog post on why this is important for improving the state of PHP:
http://bergie.iki.fi/blog/composer_solves_the_php_code-shari...
Re: What PHP 5.5 might look like
#44No matter how much PHP is improved upon, until there is a serious contender framework for it like Rails or Django, PHP will continue its route to extinction. Dinosaurs were once big and powerful. They dominated the landscape. They don't exist anymore.
billpatrianakos: FYI, it appears you've been hellbanned, presumably from the last PHP megathread (judging by your comment history and when they started going dead). Might want to contact pg about it.
Re: What PHP 5.5 might look like
#45Earlier quoted context omitted.
I've been using Cake since around 1.1 and it started with a decent base but was not very consistent. I just recently upgraded to 2.2 and I was extremely surprised with the amount of refactor and polish in order to make it a very consistent and powerful framework. It's really top notch nowadays. The performance is also better (used to have to do some "hacks" to get good performance before) but I'm not sure how it comp…
To be fair, the biggest problem I have with Cake is its ORM; it just feels unnatural to me. You ask for some data, and get back an associative array of values, which you can't do anything with but pass elsewhere. It just lacks a certain sense of OOPiness for me :)
I feel the same way, and I've been trying to get away from Cake for a while, but the fact that everything except the quirkiness of the ORM is so nice that I stick with it.
Also, the next version is supposed to redo the ORM to return actual models.
Re: What PHP 5.5 might look like
#46Regarding the "constant dereferencing" proposal, how do you even make a language parser that can't apply array operations to literals in the first place? I'm trying very hard not to bash on PHP here, and this is a completely honest question. I can't figure out how you'd even go about breaking that if you wanted to. Anyone know the background there?
Re: What PHP 5.5 might look like
#47These sound like useful improvements, especially the new getter/setter syntax and scalar type hinting. However, what I'd really like to see in next PHP would be the Composer dependency manager bundled in, a bit like Node.js nowadays ships with NPM. This has really brought a new world of cross-project code sharing into PHP: http://packagist.org/ I wrote a blog post on why this is important for improving the state of P…
I think composer is a bit too young to introduce into the language. Perhaps it will prove out to be robust, but I'd wait a little while before introducing it to core...
Re: What PHP 5.5 might look like
#48Pretty exciting, though empty() should be deprecated, not improved upon. The bit about getting the fully qualified class name is important, but it still prevents you from doing something like: function builder_factory( $var ) { $class = $some_array[ $var ]; return new $class(); } So you have to write a ton of boilerplate for something that used to be easy without namespaces, or write namespace traversal into your PHP…
Better than parameter skipping would be named parameters so you could just do: function foo($a, $b="10", $c="5", $d="3") { /* .. */ } foo(5, $c="10"); That way $a == 5, $b == "10", $c == "10", and $d == "3". Much better and cleaner syntax in my opinion and a lot of other languages support something similar.
The problem with that is it's already valid syntax with a different meaning.
function foo($a, $b = "10", $c = "20") {}
foo(1, $c=20);
var_dump($c); // int(20)
foo(5, c: 30)
foo(5, $c: 30);
foo(5, $c => 30)
Re: What PHP 5.5 might look like
#49Earlier quoted context omitted.
The article clearly states that there are more features like a read-only keyword. https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
That's not what he's referring to. He's specifically referring to a read-only that only affects external classes. So, the object itself could write to that field, but nothing else could.
You can set the visibility of both the properties and the getters/setters.
class Foo {
private $fuzz;
protected $Bar {
get { return $this->fuzz; }
private set { $this->fuzz = $value; }
}
}Re: What PHP 5.5 might look like
#50Earlier quoted context omitted.
That's not what he's referring to. He's specifically referring to a read-only that only affects external classes. So, the object itself could write to that field, but nothing else could.
You can set the visibility of both the properties and the getters/setters. class Foo { private $fuzz; protected $Bar { get { return $this->fuzz; } private set { $this->fuzz = $value; } } }
Yes. I understand that.
My point was just that he specifically wanted a read-only.