A quick question to the Dev Team. As far as I see You Guys decided to move to Github with Yii 2. Will you do the initial development on Github as well or you will move just when Yii 2 is in alpha or something?
A quick question to the Dev Team. As far as I see You Guys decided to move to Github with Yii 2. Will you do the initial development on Github as well or you will move just when Yii 2 is in alpha or something?
Alpha will be there. Initial development is in a private repo.
With namespaces, now it is possible to have multiple classes with the same name under differente namespaces. Are the classes going to be named still with the "C" prefix? I think that this prefix dirties the code.
CGeorge… please read all the posts in the Design Section for Yii 2.0.0… as the namespaces has already being discussed…
I talked to mdomba and there have been a misunderstanding. I asked for the C prefix (not for the namespaces) because I saw these posts:
http://www.yiiframework.com/forum/index.php?/topic/22325-codebase-namespace-migration-script/
mdomba just explained me that Yii 2.0 will not have the "C" prefix, thank you very much!
I don’t think that’s a valid argument. Most professionals won’t have any trouble updating their server, and by the time Yii 2.0 is released, it will be more than stable.
I think you’re right, there should be no problem keeping behaviors and developers can use PHP traits if they like. What I think is a problem, is the development time. I don’t like the Yii team spending hours programming behaviors, if PHP supports the same functionality natively. To support variables in traits, what about implementing some getter and setter methods to cover an array of values?
Dreamhost has PHP 5.2 currently. They will most probably upgrade to 5.3 by the time Yii 2 arrives.
Setting the bar for 5.4 without a really good reason would be Yii-killing IMO.
Just because Dreamhost has 5.2 doesn’t mean Yii shouldn’t move to 5.3 (or 5.4)…
Not what is in discussion, but FYI Dreamhost supports PHP 5.3: http://wiki.dreamhost.com/PHP.ini#PHP_5.3.
It does.
So it was a too little coffee comment made by me. 
The cli still says 5.2 though, but I am probably able to change it.
However, if the bar is set too high, and people need to go VPS to use Yii, then people could move to Node.js instead.
One of the main reasons why I still use PHP is that it runs practically anywhere.
At this point, I guess that 5.3 is a safe bet for most (if not all) providers, so in a couple of years from now (maybe when final 2.0 will be released), 5.3 is ok to be the minimum requirement.
Analyzed that and can’t say that traits are covering everything Yii 1.1 behaviors are affording.
How about the rest of those professionals and not-so professionals?
As much as I would like Yii to take advantage of PHP 5.4 features, my vote will still be on PHP 5.3 
I totally agree.
And it looks like the Yii team is sensible enough to pick 5.3.
A large portion of Yii users don’t have the luxury of a vps.
Convert private properties to protected please!
grigori
We will definitely not go this way for ALL private properties since it’s very extreme: once a variable or method is set to protected we can’t change it anymore. That can mean framework development will be stucked because of backwards compatibility issues.
I prefer protected attribute instead backwards compatibility: with private attributes sometimes you need to clone the whole class in order to override an only one function.
Yii is clearly focused as a RAD framework. With Yii’s conventions it is possible for developers to quickly get apps up and running that cover a broad range of goals.
Symfony2 on the other hand is super explicit.
Now why not build Yii 2.0 on top of Symfony2, aka add all the conventions of Yii on top of Symfony2’s modern architecture that already delivers all of the points mentioned my the original poster? This would turbo boost Yii 2.0 on many levels. For one a lot of the heavy lifting would already be done. Second it would give Yii 2.0 devs access to all the things the Symfony2 community has been building over the past months. Finally it would enable users to move between Symfony2 and Yii 2.0 depending on their current needs.
Surely there will be a lot of Symfony2 developers that will have projects where the Yii conventions make perfect sense. At the same time there will be cases where Yii 2.0 developers will want to throw out the conventions when they are doing something totally out of the ordinary where the conventions get in the way.
you might be interested in this blog post on the topic http://fabien.potencier.org/article/47/pragmatism-over-theory-protected-vs-private
Lukas, I doubt it will be a good move for Yii:
Symfony2 has definitely higher learning curve and it will be added to learning Yii conventions (btw., there’s not much in Yii you really shall follow).
Symfony2 will add much more internal complexity.
Symfony2 API is written in a slightly different style. I doubt we really need DI for nearly every framework part.
We have a good set of components developers like and we don’t want to just throw these away.
Even current Yii 1.1 can load PSR-0 namespaced classes so one can use Symfony2 components if needed.
Fabien’s post is a good one. Qiang did like that from the very beginning of Yii, as I remember.