Improved code quality

[FelixJacobi]

@SamuelWei Interested in your thoughts ;) .

fix #177
fix #162

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.11%. Comparing base (40494d0) to head (a623baf).

Additional details and impacted files

@@             Coverage Diff              @@
##                6.0     #188      +/-   ##
============================================
- Coverage     99.13%   99.11%   -0.03%     
+ Complexity      440      439       -1     
============================================
  Files            52       52              
  Lines          1037     1013      -24     
============================================
- Hits           1028     1004      -24     
  Misses            9        9              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[FelixJacobi]

• We must fine tune rector, to not add readonly on wrong properties.
• Review each change very carefully, Tests seems to be running for now.
• Rector cannot modernize 100%, manual short check if anything planned for 6.0 is really done.

[SamuelWei]

I think we should move all enums to the same folder/namespace.

However this is a BC. I suggest

1. Copy the current enum classes to the enum folder and refactor using the logic used in 5.x
2. Replacing the consts in the current namespace using aliases and deprecate all
3. Refactor to native enums in 6.0 and remove old classes

[FelixJacobi]

I think we should move all enums to the same folder/namespace.

However this is a BC. I suggest

1. Copy the current enum classes to the enum folder and refactor using the logic used in 5.x

2. Replacing the consts in the current namespace using aliases and deprecate all

3. Refactor to native enums in 6.0 and remove old classes

I think, since adding types and enums to the whole code base is already a change with big impact, I would schedule code restructuring (e.g. where to place classes) for 7.0.

From consumer perspective, the good thing for now, that the baked enums on using works like the constants and mabe classes before, you don't need to change your code when upgrading. And remember: 6.0 cannot trigger new deprecations ;) (ok, except for the one in the BigBlueButton constructor, which was needed to catch typing issues when the class is initialized without environment).

[FelixJacobi]

To add enums here is practical, I think, we cannot introduce and use them in 5.x, since that one must still support PHP 7.4. In 5.x and 6.1, it also would mean being a breaking change.

In theory, it could introduce a few breaking changes, therefor it fits perfectly into a major release.

[SamuelWei]

To add enums here is practical, I think, we cannot introduce and use them in 5.x, since that one must still support PHP 7.4. In 5.x and 6.1, it also would mean being a breaking change.

In theory, it could introduce a few breaking changes, therefor it fits perfectly into a major release.

I opened #197 to show my proposed solution to move all enums to a new namespace first, allowing us to convert them to native enums later

[FelixJacobi]

@SamuelWei I've rebased this against master. When this was reviewed, I think we can lift of version 6.0 🚀 after ensuring all deprecated features were removed from 6.0 branch.