Yii3 Properties

(Alexander Makarov) #62

Overall I understand the concerns but, despite that I was originally planning Yii 2 evolution, some very core things in Yii 2 leading to code that is hard to test and eventually (could be avoided with experience) to maintenance hell in long term projects. Fixing these resulted in all the changes you now see.

I understand that releasing a new version that mostly built on new concepts may drive many community members away but I still think that’s the right direction to move to.

(Oleg) #63

I think it was a good idea to evolve Yii2, you just need to call it Yii3 :slight_smile:

(Insolita) #64

Your arguments only confirm my point that you don’t need upgrade to Yii 3. Many projects also stayed on Yii1 with same reason - because profit from upgrade was less than upgrade expense. It is ok. And even Yii1 alive till now. So you don’t warry about Yii2 it has enough community and it will be alive as good RAD framework. Yii3 can bring something more for those that ready to get it.

(Alexander Makarov) #65

It was a great idea until it proved to fail solving some very important issues I’ve described above.

(mikem) #66

Except of course I wouldn’t be here having the discussion if I were intending to stay w/ Yii2 for new development…

I am in the midst of planning a new development project which will require significant investment - so it only seems prudent to ensure I understand and have considered all aspects of what is happening within the various frameworks and languages, up to and including building a new framework even.

On the other hand, with significant code re-use and such from Yii2, there’s also savings to be realized under certain scenarios. So just trying to balance everything.

Please don’t mis-understand - I’m not arguing for staying with Yii2 or keeping things static, or even attempting to be critical. I’m trying to understand the thinking and rationale behind the changes for Yii3, and the resulting cost/benefit/risk analysis. Having read much of what I could find on the background between “2.1” and Yii3, I’m just not seeing the upside to the changes, and so the underlying rationale makes less sense as a result.

Similarly, when I see statements about how “Yii2 hit a wall”, and then going on to explain how it will be supported and maintained going forward, it seems something of a contradiction from where I’m sitting. If it has hit a wall and can progress no further, how will it be maintained in a reliable manner…? If the changes are a necessary outcome from this fact, then it would seem that staying with Yii2 is a fool’s errand - it cannot be fixed, radical architectural changes are required, and so the probability of it being successfully supported over the next X number of years is low.

But I should stay with Yii2…? Perhaps you can see the basis of my confusion…

An analogy might be having a document titled “Strategy” containing a list of low-level tactical decisions…

(mikem) #67

Thing is, many of the concepts I’m considering are not actually orthogonal or in conflict with what I’ve seen cited as these “core things”. They’re not precluded by what you’re considering, nor are they the root cause of “maintenance hell”. In many ways, I think they’re just being over-looked, simply because they’re implicit or structural in nature instead of being explicit features. Think of it as a venn diagram of sorts - not all framework developers run said framework in large production scenarios, and not all application developers write framework code, while the middle tends to be a rather small minority. So one can see why different groups would value different aspects of the same codebase…

To that end, what is the current, best / definitive reference on the specific maintenance problems of Yii2 and the resulting mapping to the current solutions space? (i.e. what is wrong, and how do these changes solve the issue?). I’ve read what I can find, but perhaps I’m missing something.

One other thought: “maintenance hell” is virtually inevitable on long-term projects. Every change has an entropy cost, and so the more you change, the more disorder is created. Some changes move to disorder faster than others, but they all get there eventually. It is the same as the concept of the heat-death of the universe, just on a (much) shorter time scale. (Or, if the were not the case, would we still t be recycling old ideas all the time in new development…?) This is essentially what determines the useful life of a block of code, or a whole project.

The question isn’t whether it can be avoided, the question is at what point do you start over, and what do you take with you when you do? That’s what I’m really on about here - I need X capabilities which lead to Y requirements, and so how close is Z to Y, and what are the deltas required to close the gap…?

Sometimes those aren’t even technical, and/or aren’t even enumerated. (we need X resources to do Y in actuality, but no one ever bothers calculating X, and so Y is then by default impossible…)

So it just comes down to the trades and understanding the “why” behind them. That’s what I’m after here…

(Alexander Makarov) #68

I’ve put together a document https://github.com/yiisoft/docs/blob/master/009-design-decisions.md

If you have specific questions, feel free to ask on why X was removed/changed. I’ll add to the document.

Correct. In Yii 2 design decisions such as service locator availability (when abused) or public properties (yes, you can use magic getters), result in exponential raise of entropy. These were observed in numerous projects. Of course, long term projects are entirely possible with Yii 2 but you should be careful with these handy ones that raise entropy significantly.

(Oleg) #69

All these “problems” of Yii2 were a trade-offs for simplicity.
For me, it feels like that some fragility, some testing problems, and some tight coupling are plausible tradeoffs for development speed.
Most projects in PHP will not face those problems you described, but 100% project will face increased complexity.

In my opinion problems you described in “design decisions” do not really important

We still can use setters in dumb way. And public properties does not make our application to much fragile. Loose typing does it fragile.

Regarding testing. In “new” way we need to think how to instantiate all these service to test a single class. I personally do not see problem just to use Yii::$app in tests.

Extracting Yii packages just give possibility they become popular with cost of higher complexity for main users. For example you already need yii-dev to handle complexity, and it is just beggning.

In general I believe it is impossible to two sit on two chars: to make simple, performant and in the same time SOLID in PHP. For me Symfony is a good example, good coded, but I need at least double mental work to develop in it. Also I believe that there are god principles, for example DRY. In new Yii I need do same things over and over again, for example putting services in controller constructor.


That. Third generation of Yii is coming and for the third time nobody cares about migration path…

(Alexander Makarov) #71

It would be hard but we do care. See https://github.com/yiisoft/yii2/pull/17607 for example. We’re trying to make it easier but since there are conceptual changes, it won’t be easy.