Use more PHP standards (namespaces)

Not just namespaces .. Traits , interfaces and others must be added to CI.
Even base PHP interfaces and class's as Iterator, ArrayAccess, Serializable, Closure, can be used on some places..

CI must go closer to PHP base practices in OOP programming..

Couldn't explain it better. I think this is a must, and CodeIgniter should move towards modern best practices in PHP.

Not just namespaces .. Traits , interfaces and others must be added to CI.
Even base PHP interfaces and class's as Iterator, ArrayAccess, Serializable, Closure, can be used on some places..

CI must go closer to PHP base practices in OOP programming..

Couldn't explain it better. I think this is a must, and CodeIgniter should move towards modern best practices in PHP.

I agree, too. Keeping the syntax as $this->... is 2005 era PHP.

Great find about PHP STD.

viraltalks

I Think the new CI version MUST uses PSR too. The class names are a mess.

PHP is Life!!! See My Portfolio

I Think the new CI version MUST uses PSR too. The class names are a mess.

They were a mess in CI2.
Nothing messy about them in CI3 - Ucfirst is the rule.

Unfortunately Ucfirst is not the rule to PSR.

When I have spoken about the mess, I was referring about this. In controller you can use WelcomeTeste, Welcome_Teste or Welcome_teste, but not use the same way in model we need use Welcome_teste_model. To me this is a mess.

PHP is Life!!! See My Portfolio

While CI does not follow any of the PSRs, the current rules are much closer to PSR-1/PSR-4 than the previous rules.

More importantly, there's nothing stopping you from setting up Composer and loading your own PSR-1/PSR-2 classes to use in your application.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

Short-term backwards compatibility is how any platform maintains its existing user base, whether it is an OS, a programming language, an API, or a framework. Even if it requires an extra compatibility layer, it is usually worth the extra effort to provide an easier upgrade path for existing users.

The reason for this is simple: if I have to rewrite my existing application from scratch to move from CI3 to CI4, I then have one more reason to evaluate other frameworks and one less reason to stay with CI.

Some other PHP frameworks have resisted providing backwards compatibility, and many of them have suffered for it.

Yes. Why should we rewrite our application in every year or every 3 year?
It would be awesome if my CI application will work after 10 or 20 years!

I don't know it is possible or not. Maybe impossible. But backwards compatibility
is important for some projects.

We can write both code like below on CI3 now (using Compser):

Code:

$this->load->model('Product_model');

$product = new App\Model\Entities\Product;

If `$this->load->model()` will be removed, all existing users will have to rewrite
their applications to just load models. This is just an example of BC break.

I hope not to force rewrite and CI keep BC as possible. Keeping API is one of the
pros of CI, I think.

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

for sure i can tell you that if the next version of CodeIgniter forces me to rewrite my application, then i'll rewrite it on Laravel...

backwards compatibility is one of the main reasons why i still developing with CI and i love it..

Go for it! But please make it backwards compatible!