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 ( 987a44...b5125b )
by Shea
03:14
created

LocalRepository::getProperty()   A

Complexity

Conditions 1
Paths 1

Size

Total Lines 6
Code Lines 3

Duplication

Lines 0
Ratio 0 %

Importance

Changes 1
Bugs 0 Features 0
Metric Value
c 1
b 0
f 0
dl 0
loc 6
rs 9.4285
cc 1
eloc 3
nc 1
nop 2
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
17
		$modules   = collect();
18
19
		$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...
20
			$modules->put($module, $this->getProperties($module));
21
		});
22
23
		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...
24
	}
25
26
	/**
27
	* Get all module slugs.
28
	*
29
	* @return Collection
30
	*/
31
	public function slugs()
32
	{
33
		$slugs = collect();
34
35
		$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...
36
			$slugs->push($item['slug']);
37
		});
38
39
		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...
40
	}
41
42
	/**
43
	 * Get modules based on where clause.
44
	 *
45
	 * @param  string  $key
46
	 * @param  mixed   $value
47
	 * @return Collection
48
	 */
49
	public function where($key, $value)
50
	{
51
		$collection = $this->all();
52
53
		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...
54
	}
55
56
	/**
57
	 * Sort modules by given key in ascending order.
58
	 *
59
	 * @param  string  $key
60
	 * @return Collection
61
	 */
62
	public function sortBy($key)
63
	{
64
		$collection = $this->all();
65
66
		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...
67
	}
68
69
	/**
70
	* Sort modules by given key in ascending order.
71
	*
72
	* @param  string  $key
73
	* @return Collection
74
	*/
75
	public function sortByDesc($key)
76
	{
77
		$collection = $this->all();
78
79
		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...
80
	}
81
82
	/**
83
	 * Determines if the given module exists.
84
	 *
85
	 * @param  string  $slug
86
	 * @return bool
87
	 */
88
	public function exists($slug)
89
	{
90
		return $this->slugs()->contains(strtolower($slug));
91
	}
92
93
	/**
94
	 * Returns count of all modules.
95
	 *
96
	 * @return int
97
	 */
98
	public function count()
99
	{
100
		return $this->all()->count();
101
	}
102
103
	/**
104
	 * Get a module's properties.
105
	 *
106
	 * @param  string $slug
107
	 * @return Collection|null
108
	 */
109
	public function getProperties($slug)
110
	{
111
		if (! is_null($slug)) {
112
			$module     = studly_case($slug);
113
			$path       = $this->getManifestPath($module);
114
			$contents   = $this->files->get($path);
115
			$collection = collect(json_decode($contents, true));
116
117
			if (! $collection->has('order')) {
118
				$collection->put('order', 9001);
119
			}
120
121
			if (! $collection->has('enabled')) {
122
				$collection->put('enabled', $this->isEnabled($collection->get('slug')));
123
			}
124
125
			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...
126
		}
127
128
		return null;
129
	}
130
131
	/**
132
	 * Get a module property value.
133
	 *
134
	 * @param  string $property
135
	 * @param  mixed  $default
136
	 * @return mixed
137
	 */
138
	public function getProperty($property, $default = null)
139
	{
140
		list($module, $key) = explode('::', $property);
141
142
		return $this->getProperties($module)->get($key, $default);
143
	}
144
145
	/**
146
	* Set the given module property value.
147
	*
148
	* @param  string  $property
149
	* @param  mixed   $value
150
	* @return bool
151
	*/
152
	public function setProperty($property, $value)
153
	{
154
		list($module, $key) = explode('::', $property);
155
156
		$module  = strtolower($module);
157
		$content = $this->getProperties($module);
158
159
		if (isset($content[$key])) {
160
			unset($content[$key]);
161
		}
162
163
		$content[$key] = $value;
164
		$content       = json_encode($content, JSON_PRETTY_PRINT);
165
166
		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...
167
	}
168
169
	/**
170
	 * Get all enabled modules.
171
	 *
172
	 * @return Collection
173
	 */
174 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...
175
	{
176
        $moduleCache = $this->getCache();
177
178
        $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...
179
            $item['enabled'] = $moduleCache->get($item['slug']);
180
181
            return $item;
182
        });
183
184
		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...
185
	}
186
187
	/**
188
	 * Get all disabled modules.
189
	 *
190
	 * @return Collection
191
	 */
192 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...
193
	{
194
        $moduleCache = $this->getCache();
195
196
        $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...
197
            $item['enabled'] = $moduleCache->get($item['slug']);
198
199
            return $item;
200
        });
201
202
		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...
203
	}
204
205
	/**
206
	 * Check if specified module is enabled.
207
	 *
208
	 * @param  string $slug
209
	 * @return bool
210
	 */
211
	public function isEnabled($slug)
212
	{
213
        $moduleCache = $this->getCache();
214
215
        return $moduleCache->get($slug) === true;
216
	}
217
218
	/**
219
	 * Check if specified module is disabled.
220
	 *
221
	 * @param  string $slug
222
	 * @return bool
223
	 */
224
	public function isDisabled($slug)
225
	{
226
        $moduleCache = $this->getCache();
227
228
        return $moduleCache->get($slug) === false;
229
	}
230
231
	/**
232
	 * Enables the specified module.
233
	 *
234
	 * @param  string $slug
235
	 * @return bool
236
	 */
237
	public function enable($slug)
238
	{
239
        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...
240
	}
241
242
	/**
243
	 * Disables the specified module.
244
	 *
245
	 * @param  string $slug
246
	 * @return bool
247
	 */
248
	public function disable($slug)
249
	{
250
        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...
251
	}
252
253
    /**
254
     * Refresh the cache with any newly found modules.
255
     *
256
     * @return bool
257
     */
258
    public function cache()
259
    {
260
        $cacheFile = storage_path('app/modules.json');
261
        $cache     = $this->getCache();
262
        $modules   = $this->all();
263
264
        $collection = collect([]);
265
266
        foreach ($modules as $module) {
267
            $collection->put($module['slug'], true);
268
        }
269
270
        $keys    = $collection->keys()->toArray();
271
        $merged  = $collection->merge($cache)->only($keys);
272
        $content = json_encode($merged->all(), JSON_PRETTY_PRINT);
273
274
        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...
275
    }
276
277
    /**
278
     * Get the contents of the cache file.
279
     *
280
     * The cache file lists all module slugs and their
281
     * enabled or disabled status. This can be used to
282
     * filter out modules depending on their status.
283
     *
284
     * @return Collection
285
     */
286
    public function getCache()
287
    {
288
        $cacheFile = storage_path('app/modules.json');
289
290
        if (! $this->files->exists($cacheFile)) {
291
            $modules = $this->all();
292
            $content = [];
293
294
            foreach ($modules as $module) {
295
                $content[$module['slug']] = true;
296
            }
297
298
            $content = json_encode($content, JSON_PRETTY_PRINT);
299
300
            $this->files->put($cacheFile, $content);
301
302
            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...
303
        }
304
305
        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...
306
    }
307
308
    /**
309
     * Set the given cache key value.
310
     *
311
     * @param  string  $key
312
     * @param  mixed  $value
313
     * @return int
314
     */
315
    public function setCache($key, $value)
316
    {
317
        $cacheFile = storage_path('app/modules.json');
318
        $content   = $this->getCache();
319
320
        $content->put($key, $value);
321
322
        $content = json_encode($content, JSON_PRETTY_PRINT);
323
324
        return $this->files->put($cacheFile, $content);
325
    }
326
}
327