Completed
Push — master ( 7181b9...0b9694 )
by Silvan
01:31
created

Module   A

Complexity

Total Complexity 13

Size/Duplication

Total Lines 83
Duplicated Lines 0 %

Coupling/Cohesion

Components 0
Dependencies 3

Test Coverage

Coverage 59.09%

Importance

Changes 0
Metric Value
wmc 13
lcom 0
cbo 3
dl 0
loc 83
ccs 13
cts 22
cp 0.5909
rs 10
c 0
b 0
f 0

4 Methods

Rating   Name   Duplication   Size   Complexity  
A onLoad() 0 8 1
A t() 0 4 1
A jsonLoad() 0 10 2
C slickConfig() 0 23 9
1
<?php
2
3
namespace dev7ch\slick;
4
5
/**
6
 * Slick.js slider LUYA module.
7
 *
8
 * @author Silvan Hahn <[email protected]>
9
 */
10
class Module extends \luya\base\Module
11
{
12
    /**
13
     * {@inheritdoc}
14
     */
15
16 2
    public static function onLoad()
17
    {
18 2
        self::registerTranslation('slick*', static::staticBasePath().'/messages', [
19 2
            'fileMap' => [
20
                'slick' => 'slick.php',
21
            ],
22
        ]);
23 2
    }
24
25
    /**
26
     * Translations.
27
     *
28
     * @param $message
29
     * @param array $params
30
     * @param $category
31
     * @internal param unknown $language
32
     * @return string
33
     */
34
35 1
    public static function t($message, array $params = [], $category = 'slick')
36
    {
37 1
        return parent::baseT($category, $message, $params);
0 ignored issues
show
Documentation introduced by
$category is of type string, but the function expects a object<luya\base\unknown>.

It seems like the type of the argument is not accepted by the function/method which you are calling.

In some cases, in particular if PHP’s automatic type-juggling kicks in this might be fine. In other cases, however this might be a bug.

We suggest to add an explicit type cast like in the following example:

function acceptsInteger($int) { }

$x = '123'; // string "123"

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
Comprehensibility Bug introduced by
It seems like you call parent on a different method (baseT() instead of t()). Are you sure this is correct? If so, you might want to change this to $this->baseT().

This check looks for a call to a parent method whose name is different than the method from which it is called.

Consider the following code:

class Daddy
{
    protected function getFirstName()
    {
        return "Eidur";
    }

    protected function getSurName()
    {
        return "Gudjohnsen";
    }
}

class Son
{
    public function getFirstName()
    {
        return parent::getSurname();
    }
}

The getFirstName() method in the Son calls the wrong method in the parent class.

Loading history...
38
    }
39
40
    /**
41
     * Loading and parsing of json config array.
42
     *
43
     * @param $file
44
     * @return string
45
     * @throws \luya\Exception
46
     * @internal param string $message
47
     * @internal param array $params
48
     */
49
50
    private static function jsonLoad($file)
51
    {
52
        if (file_exists(\Yii::$app->getWebroot() . '/' . $file)) {
53
            file_get_contents(\Yii::$app->getWebroot() . '/' . $file);
54
            return  json_decode($file, true);
55
        }
56
        else {
57
            throw new  \luya\Exception('Slick.js configs:' .\Yii::$app->getWebroot() . '/' . $file . ' was not found.');
58
        }
59
    }
60
61
    /**
62
     * Load Slick.js options via LUYA configs as $params.
63
     *
64
     * @return  boolean | string | array
65
     * @internal param array $params
66
     *
67
     */
68
69 1
    public static function slickConfig() {
70
71 1
        $params = self::getInstance()->params;
72
73 1
        if (array_key_exists( 'slickConfig', $params) && $params['slickConfig'] === true) {
74
75
            return self::jsonLoad('slick-config.json');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return self::jsonLoad('slick-config.json'); (string) is incompatible with the return type documented by dev7ch\slick\Module::slickConfig of type boolean.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
76
        }
77
78 1
        if (array_key_exists( 'slickConfig', $params) && is_string($params['slickConfig']) ) {
79
            return self::jsonLoad($params['slickConfig']);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return self::jsonLoad($params['slickConfig']); (string) is incompatible with the return type documented by dev7ch\slick\Module::slickConfig of type boolean.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
80
        }
81
82 1
        if (array_key_exists( 'slickConfig', $params) && is_array($params['slickConfig'])) {
83
            return $params['slickConfig'];
84
        }
85
86 1
        if (array_key_exists( 'slickConfig', $params) && is_bool($params['slickConfig'] === false)) {
87
            return false;
88
        }
89
        
90 1
        return false;
91
    }
92
}
93