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 ( 3cdaf4...ca2904 )
by Shea
03:47
created

LocalRepository::enable()   A

Complexity

Conditions 1
Paths 1

Size

Total Lines 4
Code Lines 2

Duplication

Lines 0
Ratio 0 %

Importance

Changes 2
Bugs 0 Features 0
Metric Value
c 2
b 0
f 0
dl 0
loc 4
rs 10
cc 1
eloc 2
nc 1
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
			if (! $collection->has('order')) {
121
				$collection->put('order', 9001);
122
			}
123
124
			if (! $collection->has('enabled')) {
125
				$collection->put('enabled', $this->isEnabled($collection->get('slug')));
126
			}
127
128
			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...
129
		}
130
131
		return null;
132
	}
133
134
	/**
135
	 * Get a module property value.
136
	 *
137
	 * @param  string $property
138
	 * @param  mixed  $default
139
	 * @return mixed
140
	 */
141
	public function getProperty($property, $default = null)
142
	{
143
		list($module, $key) = explode('::', $property);
144
145
		return $this->getProperties($module)->get($key, $default);
146
	}
147
148
	/**
149
	* Set the given module property value.
150
	*
151
	* @param  string  $property
152
	* @param  mixed   $value
153
	* @return bool
154
	*/
155
	public function setProperty($property, $value)
156
	{
157
		list($module, $key) = explode('::', $property);
158
159
		$module  = strtolower($module);
160
		$content = $this->getProperties($module);
161
162
		if (isset($content[$key])) {
163
			unset($content[$key]);
164
		}
165
166
		$content[$key] = $value;
167
		$content       = json_encode($content, JSON_PRETTY_PRINT);
168
169
		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...
170
	}
171
172
	/**
173
	 * Get all enabled modules.
174
	 *
175
	 * @return Collection
176
	 */
177 View Code Duplication
	public function enabled()
0 ignored issues
show
Duplication introduced by
This method seems to be duplicated in your project.

Duplicated code is one of the most pungent code smells. If you need to duplicate the same code in three or more different places, we strongly encourage you to look into extracting the code into a single class or operation.

You can also find more detailed suggestions in the “Code” section of your repository.

Loading history...
178
	{
179
        $moduleCache = $this->getCache();
180
181
        $modules = $this->all()->map(function($item, $key) use ($moduleCache) {
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...
182
            $item['enabled'] = $moduleCache->get($item['slug']);
183
184
            return $item;
185
        });
186
187
		return $modules->where('enabled', true);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $modules->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...
188
	}
189
190
	/**
191
	 * Get all disabled modules.
192
	 *
193
	 * @return Collection
194
	 */
195 View Code Duplication
	public function disabled()
0 ignored issues
show
Duplication introduced by
This method seems to be duplicated in your project.

Duplicated code is one of the most pungent code smells. If you need to duplicate the same code in three or more different places, we strongly encourage you to look into extracting the code into a single class or operation.

You can also find more detailed suggestions in the “Code” section of your repository.

Loading history...
196
	{
197
        $moduleCache = $this->getCache();
198
199
        $modules = $this->all()->map(function($item, $key) use ($moduleCache) {
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...
200
            $item['enabled'] = $moduleCache->get($item['slug']);
201
202
            return $item;
203
        });
204
205
		return $modules->where('enabled', false);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $modules->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...
206
	}
207
208
	/**
209
	 * Check if specified module is enabled.
210
	 *
211
	 * @param  string $slug
212
	 * @return bool
213
	 */
214
	public function isEnabled($slug)
215
	{
216
        $moduleCache = $this->getCache();
217
218
        return $moduleCache->get($slug) === true;
219
	}
220
221
	/**
222
	 * Check if specified module is disabled.
223
	 *
224
	 * @param  string $slug
225
	 * @return bool
226
	 */
227
	public function isDisabled($slug)
228
	{
229
        $moduleCache = $this->getCache();
230
231
        return $moduleCache->get($slug) === false;
232
	}
233
234
	/**
235
	 * Enables the specified module.
236
	 *
237
	 * @param  string $slug
238
	 * @return bool
239
	 */
240
	public function enable($slug)
241
	{
242
        return $this->setCache($slug, true);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->setCache($slug, 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...
243
	}
244
245
	/**
246
	 * Disables the specified module.
247
	 *
248
	 * @param  string $slug
249
	 * @return bool
250
	 */
251
	public function disable($slug)
252
	{
253
        return $this->setCache($slug, false);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->setCache($slug, 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...
254
	}
255
256
    /**
257
     * Refresh the cache with any newly found modules.
258
     *
259
     * @return bool
260
     */
261
    public function cache()
262
    {
263
        $cacheFile = storage_path('app/modules.json');
264
        $cache     = $this->getCache();
265
        $modules   = $this->all();
266
267
        $collection = collect([]);
268
269
        foreach ($modules as $module) {
270
            $collection->put($module['slug'], true);
271
        }
272
273
        $keys    = $collection->keys()->toArray();
274
        $merged  = $collection->merge($cache)->only($keys);
275
        $content = json_encode($merged->all(), JSON_PRETTY_PRINT);
276
277
        return $this->files->put($cacheFile, $content);
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this->files->put($cacheFile, $content); (integer) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...ositoryInterface::cache 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...
278
    }
279
280
    /**
281
     * Get the contents of the cache file.
282
     *
283
     * The cache file lists all module slugs and their
284
     * enabled or disabled status. This can be used to
285
     * filter out modules depending on their status.
286
     *
287
     * @return Collection
288
     */
289
    public function getCache()
290
    {
291
        $cacheFile = storage_path('app/modules.json');
292
293
        if (! $this->files->exists($cacheFile)) {
294
            $modules = $this->all();
295
            $content = [];
296
297
            foreach ($modules as $module) {
298
                $content[$module['slug']] = true;
299
            }
300
301
            $content = json_encode($content, JSON_PRETTY_PRINT);
302
303
            $this->files->put($cacheFile, $content);
304
305
            return collect(json_decode($content, true));
0 ignored issues
show
Bug Best Practice introduced by
The return type of return collect(json_decode($content, true)); (Illuminate\Support\Collection) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...toryInterface::getCache 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...
306
        }
307
308
        return collect(json_decode($this->files->get($cacheFile), true));
0 ignored issues
show
Bug Best Practice introduced by
The return type of return collect(json_deco...et($cacheFile), true)); (Illuminate\Support\Collection) is incompatible with the return type declared by the interface Caffeinated\Modules\Cont...toryInterface::getCache 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...
309
    }
310
311
    /**
312
     * Set the given cache key value.
313
     *
314
     * @param  string  $key
315
     * @param  mixed  $value
316
     * @return int
317
     */
318
    public function setCache($key, $value)
319
    {
320
        $cacheFile = storage_path('app/modules.json');
321
        $content   = $this->getCache();
322
323
        $content->put($key, $value);
324
325
        $content = json_encode($content, JSON_PRETTY_PRINT);
326
327
        return $this->files->put($cacheFile, $content);
328
    }
329
}
330