Hmmm, why exactly we need this? I guess something new is always nice but I don't feel it, do you maybe have some examples of this feature existing in other frameworks or containers?

Hmmm, why exactly we need this? I guess something new is always nice but I don't feel it, do you maybe have some examples of this feature existing in other frameworks or containers?

Yes. Laravel for example.
https://github.com/laravel/framework/blob/6.x/src/Illuminate/Container/Container.php#L516

Oh, finally

In general I would like to see any real use case. Right now there is just example how to use it but nothing about why I should use it.

@sergeyklay

1. You can install some specific service in the container, and in the needed HMVC module you can extend this service without creating it. (Setting the headers in the service response, сhanging the template directory of the module Phalcon/Mvc/View etc)
2. When you have some resource dependent unresolved service and you do not know if it will be called in the needed module. In this case, it can be extended instead of the usual replacement.
3. Some custom service provider can extend the module provided from the Phalcon box instead of recreating it

For example:

index.php:

$di = new Di();

//common DI
$di->setShared('volt', function () use ($di) {
    $view = new \Phalcon\Mvc\View\Simple();
    $view->setViewsDir('/path/to/common/template/directory');
    return $view;
});

AdminModule.php

class Module implements Phalcon\Mvc\ModuleDefinitionInterface
{
    public function registerServices($di)
    {
        // this will be done without resolving
        $di->rebind('view', function ($di, \Phalcon\Mvc\View\Simple $view) {
            $view->setViewsDir('/path/to/admin/templates/directory');
        });
    }
}

I've run into a perfect use case for this today. So I have a shared user service in my DI. This service will return the user model of the current user, and this works well on the web front.

A long time ago, I wrote a bunch of business logic that relied upon this user service. Now we have new features/tools that require CLI tasks that also need to be able to execute this same business logic.

The trouble is, these CLI tasks need to work across multiple users at a time, not just one user per process like the web application. Naturally, you'd assume you could just create a new method that does something like this.

public static function setUser(int $user_id): void
{
    $app = self::getInstance();        
    $app->getDI()->setShared('user', function () use ($user_id) {
        return UserModel::findFirstById($user_id);
    });
}

However, this doesn't reset the DI's_sharedServices cache. Now I totally get that we can just call $app->getDI()->remove('user');, but if I could have called setShared in the first place without having to remove it first, that'd have been far more convenient from the start.

I've also only just gotten this far and read the code for this PR. I think calling this->remove(name) before we set the service (by calling this->set) is a far cleaner solution.

Thank you @TimurFlush but I have to close this for now as we won't be able to include this in 4.1
When we will refactor the DI this will be taken into consideration.