Why can't we use static objects?

Why codeigniter does not support static use of an object, or is there any to use static method i may missing?
Example:

PHP Code:

// the way we do is this
$this->input->post('username');

// can we do like this?
Input::post('username'); 


Or can we use any helper? like

PHP Code:

post('username');
view('profile', ['username' => 'rakibtg']); 


Thanks :=))

Why do you need static method call or global function?

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

There are a couple of issues preventing you from using the Input class as static.

1) There already exists an input class that is a concrete class, and it has not been namespaced, effectively "hogging" the name "Input".

2) You can't extend CI_Input with MY_Input that has static methods, or at least nothing I tried would work.

Consider this file in application/libraries:

PHP Code:

class Inpoot {


    public static $input_instance = NULL;

    // --------------------------------------------------------------------

    public static function get_instance()
    {
        if( is_null( self::$input_instance ) )
        {
            $CI =& get_instance();

            self::$input_instance = $CI->input;
        }

        return self::$input_instance;
    }

    // --------------------------------------------------------------------

    public static function __callStatic( $method, $params )
    {
        $obj = self::get_instance();

        return call_user_func_array( [ $obj, $method ], $params );
    }

    // --------------------------------------------------------------------

} 


Then in your controller, or perhaps MY_Controller:

PHP Code:

include APPPATH . 'libraries/Inpoot.php'; 


Now you have access to the Inpoot static class that gives you access to CI's Input class methods as static:

PHP Code:

echo Inpoot::get('foo'); 


This may seem silly, but it is what it is. If CodeIgniter had namespaced their Input class, then you could call my Inpoot class simply "Input", but they didn't. This kind of shows the significance of namespacing.

Expert Website Development - Temecula, CA
Community Auth For CodeIgniter 3

> If CodeIgniter had namespaced their Input class, then you could call my Inpoot class simply "Input"

What do you mean? CI's Input classname is `CI_Input` not `Input`.

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

> If CodeIgniter had namespaced their Input class, then you could call my Inpoot class simply "Input"

What do you mean? CI's Input classname is `CI_Input` not `Input`.

Oh yeah ... duh! Just change it to Input, yes it works.

Expert Website Development - Temecula, CA
Community Auth For CodeIgniter 3

There are a couple of issues preventing you from using the Input class as static.
Now you have access to the Inpoot static class that gives you access to CI's Input class methods as static: ...

Thanks skunkbad for a detail reply, it helps me to understand more on it.
I think CI should adopt some of the latest PHP specs to make it more smooth, and i think its really a urgent for the framework.
At least, CI should have:
1) Proper, basic authentication system.
2) Use of namespace
3) rest of the things are great.

Greatly appreciate your time :=)

...
At least, CI should have:
1) Proper, basic authentication system.
2) Use of namespace
...

The use of a "default" authentication "system" is only acceptable if it can be disabled by the developer.  The developer might not want to use the default authentication and must be allowed to replace it with another auth system.  I think this could be implemented as a simple configuration flag. 

That being said:

My personal choice would be to NOT include authentication with CI.  I think it is better left as a third-party tool to be integrated by the developer.  This avoids "code-bloat", which we see in competing frameworks.

namespaces are very desirable in CI 4.0, even if it mean CI becomes more complicated for the first-time user.

CI 3.1 Kubuntu 19.04 Apache 5.x  Mysql 5.x PHP 5.x PHP 7.x
Remember: Obfuscation is a bad thing.
Clarity is desirable over Brevity every time.

My personal choice would be to NOT include authentication with CI.  I think it is better left as a third-party tool to be integrated by the developer.  This avoids "code-bloat", which we see in competing frameworks.

Why not? proper implementation cant be bad, where-areas many developer (beginners) are using very poor auth system and also many devs just stopped using CI.

namespaces are very desirable in CI 4.0, even if it mean CI becomes more complicated for the first-time user.

well, first-time user this days learn Laravel or Symphony or Yii :=D

I think CI should adopt some of the latest PHP specs to make it more smooth, and i think its really a urgent for the framework.

First - some of that is definitely planned for CI 4, but it will still be a while, whether that is good or bad probably depends on how many projects you have to support currently.

However, you can't say that the use of static methods is one of the "latest PHP specs" or even good practice. Most modern best practices tell you to stay away from static methods at all costs for 2 primary reasons:

1) It's more difficult to test properly.
2) because it is static, and must maintain a static state during the entire request will NOT work correctly during HMVC controller-calling-controller type of situations because the state will get confused and out of order. That makes it a beast to debug.

I know that you're going to say that Laravel, FuelPHP2 and others use that and they're modern. But they don't. They still have instantiated classes in the background. Instead, they have hijacked a standard PHP language feature because they liked the clean syntax, and wrote another layer of abstraction on top of the system, called Facades, to make this work. This specifically seems to have come from Laravel, which was mostly static in L3. He got a lot of grief over it, so rewrote it in L4 to keep the syntax and be more "proper". In reality, this adds additional performance loss, more mental overhead for developers, and confuses new developers who don't realize what's going on. But does keep a nice clean syntax.

In case you're wondering - no, you shouldn't expect to see Facades in CI 4.

Support Development •  CodeIgniter 4 Foundations • Practical CodeIgniter 3  • CodeIgniter Tutorials

The use of a "default" authentication "system" is only acceptable if it can be disabled by the developer.  The developer might not want to use the default authentication and must be allowed to replace it with another auth system.  I think this could be implemented as a simple configuration flag. 

They really wouldn't even need a configuration flag. They could allow it to be overridden just like almost every other class in CodeIgniter, so the replacement could be as simple as dropping a MY_Authentication class into the application.

I agree with the basic idea that CI is best served by staying simple and limiting what's included in the core system, but I think people often overlook how easy CI usually makes it to override and extend the included functionality.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide