Just going to reply with some hopefully helpful advice:
There’s really nothing too magical about $app->make(). You don’t have to use it. In general, it’s useful when you have some dependencies that are globally registered that you don’t want to have to retrieve yourself in order to pass in.
So, for example, let’s say we want to use the
Concrete\Core\Filesystem\FileLocator class, in order to search the file system for some element or block templates. The class requires
Concrete\Core\Application\Application in order to do its business, and it obtains those classes in the constructor.
Instead of having to somehow instantiate the Filesystem and Application classes in order to pass them into your new FileLocator class, you can just run
Which will then auto-magically pass in the appropriate versions of those classes, either by just automatically instantiating them or by looking into one of the service provider classes and then figuring out how to build the classes.
I mention this because if there’s a class that you need to use that only takes an object that you always have on hand, there’s absolutely no reason to use $app->make(). The permissions checker class is a perfect example of this. The checker class only takes a single object – whatever object you want to check permissions on. So it doesn’t make sense to run it through $app->make() because it’s just adding overhead. This
$permissions = new Checker($block);
Is exactly the same as this
$permissions = $app->make(Checker::class, ['object' => $block]);
But the second one is a lot harder to read.
Just thought I’d mention this. If you want to read up more on why we use this approach, this document still holds up (even though it talks about Core::make() a lot – that’s exactly the same as $app->make(), it’s just you don’t have to have a $app object to work on.)