Laravel: Difference App::bind and App::singleton

It's exactly like that.

A very simple proof is to test out the behavior. Since the Laravel Application simply extends Illuminate\Container\Container, we'll use just the container (in my case I even only added the container as a dependency to my composer.json) to test.

require __DIR__ . '/vendor/autoload.php';

class FirstClass
{
    public $value;
}

class SecondClass
{
    public $value;
}

// Test bind()
$container = new Illuminate\Container\Container();

$container->bind('FirstClass');

$instance = $container->make('FirstClass');
$instance->value = 'test';

$instance2 = $container->make('FirstClass');
$instance2->value = 'test2';

echo "Bind: $instance->value vs. $instance2->value\n";

// Test singleton()
$container->singleton('SecondClass');

$instance = $container->make('SecondClass');
$instance->value = 'test';

$instance2 = $container->make('SecondClass');
$instance2->value = 'test2'; // <--- also changes $instance->value

echo "Singleton: $instance->value vs. $instance2->value\n";

The result is as expected:

Bind: test vs. test2

Singleton: test2 vs. test2

Might be a dirty proof, but indeed it is one.

All the magic lies in the Container::make method. If the binding is registered as shared (which means as singleton), the class instance is returned, otherwise a new instance every time.

Source: https://github.com/laravel/framework/blob/4.2/src/Illuminate/Container/Container.php#L442

BTW, Container::singleton is the same as Container::bind with the third parameter set to true.

Facades do work as singleton, even if the underlying binding is not a singleton.

Let's say you have:

$app->bind('foo', 'FooConcrete'); // not a singleton

and:

class Foo extends \Illuminate\Support\Facades\Facade {
    protected static function getFacadeAccessor() { return 'foo'; }
}

Then this will create 2 instances of FooConcrete, as usual:

app('foo');
app('foo');

But this will create only one instance of FooConcrete and reuse it:

Foo::someMethod();
Foo::someMethod();

It is because resolveFacadeInstance() stores the resolved instances.

There is an exception though. Most of the time the defined getFacadeAccessor() returns a string, as shown above, but it can also return an object. Example from the Schema Facade:

protected static function getFacadeAccessor() {
    return static::$app['db']->connection()->getSchemaBuilder();
}

In such a case, resolveFacadeInstance() doesn't store the instance.

So if getFacadeAccessor() returns a new instance, each call to the Facade creates a new instance as well.

But somewhere I read that Laravel treats classes called via facades always as singletons?

Thereby, I encountered this problem:

I have a demo class normally bound via

$this->app->bind('demo', function() { return new Demo(); }

An sett up a facade

protected static function getFacadeAccessor() { return 'demo'; }

The class itself looks like this

class Demo 
    {

        private $value1;        
        private $value2;        

        public function setVal1($value)
        {
            $this->value1 = $value;
        }

        public function setVal2($value)
        {
            $this->value2 = $value;
        }

        public function getVals()
        {
            return 'Val 1: ' . $this->value1 . ' Val 2: ' . $this->value2;
        }   

    }

You told me that if I would use a facade on this class, it would instantiate an object of the class and then call the method on that object.

Butt I tested some more and found this very strange (at least to me) behavior:

If I do

Demo::setVal1('13654');

and

Demo::setVal2('random string')

I shouldn't be able to use Demo::getVals() to retrieve the values I just created, should I? Since every time a facade method is used a new object will be instantiated and how can one object retrieve properties of another object? There should be three different instances but still I'm able to retrieve the properties from those other instances...