I guess I have more or less the opposite point of view.
In my opinion, a framework should be built for the latest generation of the technology it’s designed to enable - leveraging every available feature of the platform, using the latest tools and best practices available.
If you design for last year’s technology, you’re designing for the past. I would rather design for the future. There are already projects (such as Aura) designed exclusively for PHP 5.4.
In a sense, PHP has been playing "catch-up" with many other languages for years - PHP 5.4 will provide a number of features that developers have been starving for since forever.
Because the language itself has finally “grown up”, adoption by developers is going to be high - it’s already happening, and it hasn’t even officially been released yet. This will put pressure on hosting-companies pretty quick.
I think you will see much more wide-spread and quicker adoption of PHP 5.4 than previous versions.
Disagree, a framework should target the most widely available version of the platform it’s building on, in this case 5.3, otherwise you are presenting barriers to entry. We want Yii to take over the world, not be restricted by artificial constraints such as requiring the absolute latest version of PHP.
And this project will remain inaccessible to a large proportion of the PHP community for YEARS, it has zero mindshare and will be crippled by this requirement for the foreseeable future.
I think you’re being a little optimistic, while I agree we should see faster adoption than for 5.3, it will be by no means instant. Think years not months. For most businesses it’s basically irresponsible to switch to a new major PHP version before it’s had at least a year’s worth of critical bug fixes, think 5.4.4 not 5.4
Also, I’m not really sure what you’re arguing for. Traits do not provide the same functionality as behaviors. Afaik you cannot attach a trait to an object at runtime in the same way that you can a behavior, nor can you temporarily disable or selectively enable a trait. As mentioned above you’re free to use short array syntax in your application code, so does it really matter that the Yii2 code uses the normal array syntax?
Didn’t understand this, isn’t it the role of Yii 1.x to embrace, take over the world ? It did it and it continues to do it. People would still have choice between the long matured actual Yii releases line and the new innovative major release.
Long time ago, Yii were used to be seen as an innovative framework, things are changing (for good or bad, whatever, that’s not the subject) and i don’t know why as i don’t see “to be innovative” as “to be against productivy”. If i don’t make mistake, i think Yii clearly has the longest development cycle i’ve seen among php frameworks regarding major releases. That means the choice for a php 5.3 support will stay for a very, very long time… and as a result would reinforce what becomes to look like to always be one step behing everyone at least.
Clearly, if not the majority of frameworks are not supporting php 5.4 when yii 2 will be out, point me this post (or Yii 2 will be released far sooner than i think) and as they have, as mentioned, a shorter major release development release, they will even be under a new php release while we will stay with php 5.3 for still a long time coming after that.
As well as constraints, did Yii already restrict people by artificial constraints with previous php releases ?
Regarding PHP release and Yii 2, and as Yii 2.0 is so far from now, we will probably have PHP 5.4.x releases before and i don’t see them as constraints, especially if we take into account php itself has not a very fast development cycle.
In java world, the namespace will help you very much in code organization layering all your code. When you learn java you are encourage to learn the framework usage in a namespaced environment, from beginning…this is my point: introducing namespacing in yii NOW will confuse many people who learn Yii starting from a non-namespaced yii version, many projects will be affected without serious modifications.
Namespaces are great, but even with extensions and modules you always ‘extend’ from another class, therefore you wouldn’t really need it for that case.
If you do however have multiple projects running from the framework (which should cause an issue in the first place) You could use namespaces to make things easier, though in our office we are debating whether that would not make things more complicated.
Majority of php developers use tools that doesn’t even use Intellisense, and the tools that does support it (ex. PHPeD, Aptana ect…) - You barely use
