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\CheckAccessInterface
yii\view\ViewContextInterface
yii\view\DynamicContentAwareInterface
yii\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.