Decouple framework parts
hiqsol opened this issue · comments
Attempts to split framework into truly independent parts get stuck in interdependencies problem.
Example: yii\rbac\CheckAccessInterface.
At the moment it is defined in yiisoft/rbac package.
This interface is used in yii\web\User class defined in yiisoft/yii-web package.
So yii-web package should require rbac which is unacceptable.
If we put CheckAccessInterface to yii-web then rbac should require yii-web which is unacceptable even more.
That's why PSR interoperability interfaces were introduced.
And I think this solution suits the problem too.
I propose to create package with Yii interoperability interfaces - yiisoft/interfaces.
Interfaces that have this interdependence problem are:
yii\rbac\CheckAccessInterfaceyii\view\ViewContextInterfaceyii\view\DynamicContentAwareInterfaceyii\di\FactoryInterface- to be continued
Agree.
This creates a pretty big problem which PSR interfaces packages already facing in - such package is basically unupgradable. Almost every change in interface is a BC break and requires new major release. And each major release creates division in ecosystem - I'm not able to use package A which uses interfaces v1 and package B which uses interfaces v2, at the same time.
And this will be even worse if you put completely unrelated interfaces in one package - change in one interface will force to release new major release which will affect all other interfaces, even if they have not been changed.
Yes. Potentially it is a problem.
But in practice, mentioned interfaces are simple (1-3 methods) and were never changed (I've checked git history). If they've managed to stay for 2 major releases (2 and 3) I think they will do it up to 4.
Do you have better ideas?
What's about at least creating a separate package for each interface?
Yes, that may work better.
I think CheckAccessInterface of yii-web or yii-rest and rbac of CheckAccessInterface should be two separate interfaces.
Should?
rbac + other framework,
other rbac + yii framework
rbac + yii framework
The confusion now is because the names of the two interfaces are the same.
In essence, I think it is two different interfaces.
Assumption:
The interface name of rbac is different, so it will be clearer when designing
yii\view\ViewContextInterface and yii\view\DynamicContentAwareInterface Should be placed in view.
Use view for require , For example yii-web.
I think yii\web\User should not implement can method (which is using yii\rbac\CheckAccessInterface). In my opinion this is not the User responsibility. We need to create an interface in rbac package (i.e. Applicable) with the can method and realize all the permission logic there. Current problem is not in interdependencies but in violation of SOLID principles (Single Responsibility and Interface Segregation at least).
@viktorprogger I agree about RBAC. Do you want to implement it in https://github.com/yiisoft/rbac?
I think that every such big change should be discussed more before implementing/changing it. I like those propositions but i wonder whether they are good enough to introduce another braking compatibility change.
When you introduce too many changes, adoption for new version will probably be low and it will be much harder to upgrade from yii2 to yii3.
@mozarcik it's 3.0. It is all about breaking changes.
First of all, I'm not against BC changes, because without it framework won't go forward. But if you make such big changes in every major release it is very hard to upgrade from one to another. I bet there are many yii1 applications out there because it is not trivial to upgrade to yii2. With many BC changes made in yii3 many devs won't upgrade to yii3 and will stay with yii2.
I think that every BC change should be discussed whether its best to introduce change without BC, just like proposed removing can method. It is easy to add new way of checking access with leaving this method and triggering deprecated warning. This way upgrade will be easier and it would allow to developers to change all can usages during deprecation period to new way. Then in maybe 3.1 such method could be removed entirely.
Just my 2 cents.
Yii had a release cycle of 4 years for new major versions, that's outstanding compared to other frameworks.
This way upgrade will be easier and it would allow to developers to change all can usages during deprecation period to new way. Then in maybe 3.1 such method could be removed entirely.
No, this makes it way harder, because too many users/devs won't care about deprecation warnings and there'd be complaints when 3.1 is released.
@mozarcik It would be better to create bridge package with web User class and this method. Removing method in 3.1 would be against semver.
But I agree with you about BC braking changes - new major release does not mean that we can break whatever we want. Yii 3 is not a new framework, there should be some sane upgrade path from Yii 2 to Yii 3.
More or less done by now. More packages are to be extracted if needed.