GitHub Access Token became invalid

It seems like the GitHub access token used for retrieving details about this repository from GitHub became invalid. This might prevent certain types of inspections from being run (in particular, everything related to pull requests).
Please ask an admin of your repository to re-new the access token on this website.
Completed
Push — master ( 7270bd...00b768 )
by Shea
08:40 queued 04:07
created

LocalRepository::getProperties()   A

Complexity

Conditions 3
Paths 3

Size

Total Lines 17
Code Lines 10

Duplication

Lines 0
Ratio 0 %

Importance

Changes 1
Bugs 0 Features 0
Metric Value
c 1
b 0
f 0
dl 0
loc 17
rs 9.4286
cc 3
eloc 10
nc 3
nop 1
1
<?php
2
namespace Caffeinated\Modules\Repositories;
3
4
use Caffeinated\Modules\Repositories\Repository;
5
6
class LocalRepository extends Repository
7
{
8
	/**
9
	* Get all modules.
10
	*
11
	* @return Collection
12
	*/
13
	public function all()
14
	{
15
		$basenames = $this->getAllBasenames();
16
		$modules   = collect();
17
18
		$basenames->each(function($module, $key) use ($modules) {
0 ignored issues
show
Unused Code introduced by
The parameter $key is not used and could be removed.

This check looks from parameters that have been defined for a function or method, but which are not used in the method body.

Loading history...
19
			$modules->put($module, $this->getProperties($module));
20
		});
21
22
		return $modules->sortBy('order');
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $modules->sortBy('order'); (Illuminate\Support\Collection) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...epositoryInterface::all of type Caffeinated\Modules\Contracts\Collection.

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...
23
	}
24
25
	/**
26
	* Get all module slugs.
27
	*
28
	* @return Collection
29
	*/
30
	public function slugs()
31
	{
32
		$slugs = collect();
33
34
		$this->all()->each(function($item, $key) use ($slugs) {
0 ignored issues
show
Unused Code introduced by
The parameter $key is not used and could be removed.

This check looks from parameters that have been defined for a function or method, but which are not used in the method body.

Loading history...
35
			$slugs->push($item['slug']);
36
		});
37
38
		return $slugs;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $slugs; (Illuminate\Support\Collection) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...ositoryInterface::slugs of type Caffeinated\Modules\Contracts\Collection.

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...
39
	}
40
41
	/**
42
	 * Get modules based on where clause.
43
	 *
44
	 * @param  string  $key
45
	 * @param  mixed   $value
46
	 * @return Collection
47
	 */
48
	public function where($key, $value)
49
	{
50
		$collection = $this->all();
51
52
		return $collection->where($key, $value);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $collection->where($key, $value); (Illuminate\Support\Collection) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...ositoryInterface::where of type Caffeinated\Modules\Contracts\Collection.

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...
53
	}
54
55
	/**
56
	 * Sort modules by given key in ascending order.
57
	 *
58
	 * @param  string  $key
59
	 * @return Collection
60
	 */
61
	public function sortBy($key)
62
	{
63
		$collection = $this->all();
64
65
		return $collection->sortBy($key);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $collection->sortBy($key); (Illuminate\Support\Collection) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...sitoryInterface::sortBy of type Caffeinated\Modules\Contracts\Collection.

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...
66
	}
67
68
	/**
69
	* Sort modules by given key in ascending order.
70
	*
71
	* @param  string  $key
72
	* @return Collection
73
	*/
74
	public function sortByDesc($key)
75
	{
76
		$collection = $this->all();
77
78
		return $collection->sortByDesc($key);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $collection->sortByDesc($key); (Illuminate\Support\Collection) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...ryInterface::sortByDesc of type Caffeinated\Modules\Contracts\Collection.

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...
79
	}
80
81
	/**
82
	 * Determines if the given module exists.
83
	 *
84
	 * @param  string  $slug
85
	 * @return bool
86
	 */
87
	public function exists($slug)
88
	{
89
		return $this->slugs()->contains(strtolower($slug));
90
	}
91
92
	/**
93
	 * Returns count of all modules.
94
	 *
95
	 * @return int
96
	 */
97
	public function count()
98
	{
99
		return $this->all()->count();
100
	}
101
102
	/**
103
	 * Get a module's properties.
104
	 *
105
	 * @param  string $slug
106
	 * @return Collection|null
107
	 */
108
	public function getProperties($slug)
109
	{
110
		if (! is_null($slug)) {
111
			$module     = studly_case($slug);
112
			$path       = $this->getManifestPath($module);
113
			$contents   = $this->files->get($path);
114
			$collection = collect(json_decode($contents, true));
115
116
			if (! $collection->has('order')) {
117
				$collection->put('order', 9001);
118
			}
119
120
			return $collection;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $collection; (Illuminate\Support\Collection) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...nterface::getProperties of type Caffeinated\Modules\Contracts\Collection.

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...
121
		}
122
123
		return null;
124
	}
125
126
	/**
127
	 * Get a module property value.
128
	 *
129
	 * @param  string $property
130
	 * @param  mixed  $default
131
	 * @return mixed
132
	 */
133
	public function getProperty($property, $default = null)
134
	{
135
		list($module, $key) = explode('::', $property);
136
137
		return $this->getProperties($module)->get($key, $default);
138
	}
139
140
	/**
141
	* Set the given module property value.
142
	*
143
	* @param  string  $property
144
	* @param  mixed   $value
145
	* @return bool
146
	*/
147
	public function setProperty($property, $value)
148
	{
149
		list($module, $key) = explode('::', $property);
150
151
		$module  = strtolower($module);
152
		$content = $this->getProperties($module);
153
154
		if (isset($content[$key])) {
155
			unset($content[$key]);
156
		}
157
158
		$content[$key] = $value;
159
		$content       = json_encode($content, JSON_PRETTY_PRINT);
160
161
		return $this->files->put($this->getManifestPath($module), $content);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->files->put...th($module), $content); (integer) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...yInterface::setProperty 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...
162
	}
163
164
	/**
165
	 * Get all enabled modules.
166
	 *
167
	 * @return Collection
168
	 */
169
	public function enabled()
170
	{
171
		return $this->where('enabled', true);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->where('enabled', true); (Illuminate\Support\Collection) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...itoryInterface::enabled of type Caffeinated\Modules\Contracts\Collection.

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...
172
	}
173
174
	/**
175
	 * Get all disabled modules.
176
	 *
177
	 * @return Collection
178
	 */
179
	public function disabled()
180
	{
181
		return $this->where('enabled', false);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->where('enabled', false); (Illuminate\Support\Collection) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...toryInterface::disabled of type Caffeinated\Modules\Contracts\Collection.

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...
182
	}
183
184
	/**
185
	 * Check if specified module is enabled.
186
	 *
187
	 * @param  string $slug
188
	 * @return bool
189
	 */
190
	public function isEnabled($slug)
191
	{
192
		return $this->getProperty("{$slug}::enabled") === true;
193
	}
194
195
	/**
196
	 * Check if specified module is disabled.
197
	 *
198
	 * @param  string $slug
199
	 * @return bool
200
	 */
201
	public function isDisabled($slug)
202
	{
203
		return $this->getProperty("{$slug}::enabled") === false;
204
	}
205
206
	/**
207
	 * Enables the specified module.
208
	 *
209
	 * @param  string $slug
210
	 * @return bool
211
	 */
212
	public function enable($slug)
213
	{
214
		return $this->setProperty("{$slug}::enabled", true);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->setPropert...slug}::enabled", true); (integer) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...sitoryInterface::enable 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...
215
	}
216
217
	/**
218
	 * Disables the specified module.
219
	 *
220
	 * @param  string $slug
221
	 * @return bool
222
	 */
223
	public function disable($slug)
224
	{
225
		return $this->setProperty("{$slug}::enabled", false);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->setPropert...lug}::enabled", false); (integer) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...itoryInterface::disable 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...
226
	}
227
}
228