NeonContainerLoaderTrait::getContainerLoader()   A
last analyzed

Complexity

Conditions 1
Paths 1

Size

Total Lines 9
Code Lines 5

Duplication

Lines 0
Ratio 0 %

Importance

Changes 2
Bugs 1 Features 0
Metric Value
c 2
b 1
f 0
dl 0
loc 9
rs 9.6666
cc 1
eloc 5
nc 1
nop 1
1
<?php
2
3
/*
4
 * This is part of the symfonette/neon-integration package.
5
 *
6
 * (c) Martin Hasoň <[email protected]>
7
 * (c) Webuni s.r.o. <[email protected]>
8
 *
9
 * For the full copyright and license information, please view the LICENSE
10
 * file that was distributed with this source code.
11
 */
12
13
namespace Symfonette\NeonIntegration\HttpKernel;
14
15
use Symfonette\NeonIntegration\DependencyInjection\NeonFileLoader;
16
use Symfony\Component\DependencyInjection\ContainerInterface;
17
use Symfony\Component\HttpKernel\Config\FileLocator;
18
19
trait NeonContainerLoaderTrait
20
{
21
    protected function getContainerLoader(ContainerInterface $container)
22
    {
23
        /* @var $loader \Symfony\Component\Config\Loader\Loader */
24
        $loader = parent::getContainerLoader($container);
25
        $resolver = $loader->getResolver();
26
        $resolver->addLoader(new NeonFileLoader($container, new FileLocator($this)));
0 ignored issues
show
Compatibility introduced by
$container of type object<Symfony\Component...ion\ContainerInterface> is not a sub-type of object<Symfony\Component...ction\ContainerBuilder>. It seems like you assume a concrete implementation of the interface Symfony\Component\Depend...tion\ContainerInterface to be always present.

This check looks for parameters that are defined as one type in their type hint or doc comment but seem to be used as a narrower type, i.e an implementation of an interface or a subclass.

Consider changing the type of the parameter or doing an instanceof check before assuming your parameter is of the expected type.

Loading history...
27
28
        return $loader;
29
    }
30
}
31