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 — develop ( 5a4bbb...3fba13 )
by Baptiste
02:51
created

Set::valid()   A

Complexity

Conditions 1
Paths 1

Size

Total Lines 4
Code Lines 2

Duplication

Lines 0
Ratio 0 %

Code Coverage

Tests 2
CRAP Score 1

Importance

Changes 0
Metric Value
dl 0
loc 4
ccs 2
cts 2
cp 1
rs 10
c 0
b 0
f 0
cc 1
eloc 2
nc 1
nop 0
crap 1
1
<?php
2
declare(strict_types = 1);
3
4
namespace Innmind\Immutable;
5
6
use Innmind\Immutable\Exception\InvalidArgumentException;
7
8
class Set implements SetInterface
9
{
10
    use Type;
11
12
    private $type;
13
    private $spec;
14
    private $values;
15
16
    /**
17
     * {@inheritdoc}
18
     */
19 64
    public function __construct(string $type)
20
    {
21 64
        $this->type = new Str($type);
22 64
        $this->spec = $this->getSpecificationFor($type);
23 64
        $this->values = new Stream($type);
24 64
    }
25
26
    /**
27
     * {@inheritdoc}
28
     */
29 34
    public function type(): Str
30
    {
31 34
        return $this->type;
32
    }
33
34
    /**
35
     * {@inheritdoc}
36
     */
37 4
    public function size(): int
38
    {
39 4
        return $this->values->size();
40
    }
41
42
    /**
43
     * {@inheritdoc}
44
     */
45 2
    public function count(): int
46
    {
47 2
        return $this->values->size();
48
    }
49
50
    /**
51
     * {@inheritdoc}
52
     */
53 40
    public function toPrimitive()
54
    {
55 40
        return $this->values->toPrimitive();
56
    }
57
58
    /**
59
     * {@inheritdoc}
60
     */
61 2
    public function current()
62
    {
63 2
        return $this->values->current();
64
    }
65
66
    /**
67
     * {@inheritdoc}
68
     */
69 2
    public function key()
70
    {
71 2
        return $this->values->key();
72
    }
73
74
    /**
75
     * {@inheritdoc}
76
     */
77 2
    public function next()
78
    {
79 2
        $this->values->next();
80 2
    }
81
82
    /**
83
     * {@inheritdoc}
84
     */
85 2
    public function rewind()
86
    {
87 2
        $this->values->rewind();
88 2
    }
89
90
    /**
91
     * {@inheritdoc}
92
     */
93 2
    public function valid()
94
    {
95 2
        return $this->values->valid();
96
    }
97
98
    /**
99
     * {@inheritdoc}
100
     */
101 4 View Code Duplication
    public function intersect(SetInterface $set): SetInterface
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...
102
    {
103 4
        $this->validate($set);
104
105 2
        $newSet = clone $this;
106 2
        $newSet->values = $this->values->intersect(
107 2
            $set->reduce(
108 2
                $this->values->clear(),
109
                function(Stream $carry, $value): Stream {
110 2
                    return $carry->add($value);
111 2
                }
112
            )
113
        );
114
115 2
        return $newSet;
1 ignored issue
show
Bug Best Practice introduced by
The return type of return $newSet; (Innmind\Immutable\Set) is incompatible with the return type declared by the interface Innmind\Immutable\SetInterface::intersect of type self.

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...
116
    }
117
118
    /**
119
     * {@inheritdoc}
120
     */
121 54
    public function add($element): SetInterface
122
    {
123 54
        $this->spec->validate($element);
124
125 52
        if ($this->contains($element)) {
126 4
            return $this;
1 ignored issue
show
Bug Best Practice introduced by
The return type of return $this; (Innmind\Immutable\Set) is incompatible with the return type declared by the interface Innmind\Immutable\SetInterface::add of type self.

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...
127
        }
128
129 52
        $set = clone $this;
130 52
        $set->values = $this->values->add($element);
131
132 52
        return $set;
1 ignored issue
show
Bug Best Practice introduced by
The return type of return $set; (Innmind\Immutable\Set) is incompatible with the return type declared by the interface Innmind\Immutable\SetInterface::add of type self.

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...
133
    }
134
135
    /**
136
     * {@inheritdoc}
137
     */
138 52
    public function contains($element): bool
139
    {
140 52
        return $this->values->contains($element);
141
    }
142
143
    /**
144
     * {@inheritdoc}
145
     */
146 2
    public function remove($element): SetInterface
147
    {
148 2
        if (!$this->contains($element)) {
149
            return $this;
1 ignored issue
show
Bug Best Practice introduced by
The return type of return $this; (Innmind\Immutable\Set) is incompatible with the return type declared by the interface Innmind\Immutable\SetInterface::remove of type self.

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...
150
        }
151
152 2
        $index = $this->values->indexOf($element);
153 2
        $set = clone $this;
154 2
        $set->values = $this
155 2
            ->values
156 2
            ->clear()
157 2
            ->append($this->values->slice(0, $index))
158 2
            ->append($this->values->slice($index + 1, $this->size()));
159
160 2
        return $set;
1 ignored issue
show
Bug Best Practice introduced by
The return type of return $set; (Innmind\Immutable\Set) is incompatible with the return type declared by the interface Innmind\Immutable\SetInterface::remove of type self.

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...
161
    }
162
163
    /**
164
     * {@inheritdoc}
165
     */
166 4 View Code Duplication
    public function diff(SetInterface $set): SetInterface
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...
167
    {
168 4
        $this->validate($set);
169
170 2
        $newSet = clone $this;
171 2
        $newSet->values = $this->values->diff(
172 2
            $set->reduce(
173 2
                $this->values->clear(),
174
                function(Stream $carry, $value): Stream {
175 2
                    return $carry->add($value);
176 2
                }
177
            )
178
        );
179
180 2
        return $newSet;
1 ignored issue
show
Bug Best Practice introduced by
The return type of return $newSet; (Innmind\Immutable\Set) is incompatible with the return type declared by the interface Innmind\Immutable\SetInterface::diff of type self.

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...
181
    }
182
183
    /**
184
     * {@inheritdoc}
185
     */
186 12
    public function equals(SetInterface $set): bool
187
    {
188 12
        $this->validate($set);
189
190 10
        return $this->values->equals(
191 10
            $set->reduce(
192 10
                $this->values->clear(),
193
                function(Stream $carry, $value): Stream {
194 10
                    return $carry->add($value);
195 10
                }
196
            )
197
        );
198
    }
199
200
    /**
201
     * {@inheritdoc}
202
     */
203 2
    public function filter(callable $predicate): SetInterface
204
    {
205 2
        $set = clone $this;
206 2
        $set->values = $this->values->filter($predicate);
207
208 2
        return $set;
1 ignored issue
show
Bug Best Practice introduced by
The return type of return $set; (Innmind\Immutable\Set) is incompatible with the return type declared by the interface Innmind\Immutable\SetInterface::filter of type self.

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...
209
    }
210
211
    /**
212
     * {@inheritdoc}
213
     */
214
    public function foreach(callable $function): SetInterface
215
    {
216 2
        $this->values->foreach($function);
217
218 2
        return $this;
1 ignored issue
show
Bug Best Practice introduced by
The return type of return $this; (Innmind\Immutable\Set) is incompatible with the return type declared by the interface Innmind\Immutable\SetInterface::foreach of type self.

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...
219
    }
220
221
    /**
222
     * {@inheritdoc}
223
     */
224 2
    public function groupBy(callable $discriminator): MapInterface
225
    {
226 2
        $map = $this->values->groupBy($discriminator);
227
228 2
        return $map->reduce(
229 2
            new Map((string) $map->keyType(), SetInterface::class),
230
            function(Map $carry, $key, StreamInterface $values): Map {
231 2
                return $carry->put(
232
                    $key,
233 2
                    $values->reduce(
234 2
                        $this->clear(),
235
                        function(Set $carry, $value): Set {
236 2
                            return $carry->add($value);
237 2
                        }
238
                    )
239
                );
240 2
            }
241
        );
242
    }
243
244
    /**
245
     * {@inheritdoc}
246
     */
247 4
    public function map(callable $function): SetInterface
248
    {
249 4
        return $this->reduce(
250 4
            $this->clear(),
251
            function(self $carry, $value) use ($function): self {
252 4
                return $carry->add($function($value));
253 4
            }
254
        );
255
    }
256
257
    /**
258
     * {@inheritdoc}
259
     */
260 2
    public function partition(callable $predicate): MapInterface
261
    {
262 2
        $truthy = $this->clear();
263 2
        $falsy = $this->clear();
264 2
        $partitions = $this->values->partition($predicate);
265 2
        $truthy->values = $partitions->get(true);
266 2
        $falsy->values = $partitions->get(false);
267
268 2
        return (new Map('bool', SetInterface::class))
269 2
            ->put(true, $truthy)
2 ignored issues
show
Documentation introduced by
true is of type boolean, but the function expects a object<Innmind\Immutable\T>.

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

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

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

function acceptsInteger($int) { }

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

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
Documentation introduced by
$truthy is of type this<Innmind\Immutable\Set>, but the function expects a object<Innmind\Immutable\S>.

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

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

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

function acceptsInteger($int) { }

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

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
270 2
            ->put(false, $falsy);
2 ignored issues
show
Documentation introduced by
false is of type boolean, but the function expects a object<Innmind\Immutable\T>.

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

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

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

function acceptsInteger($int) { }

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

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
Documentation introduced by
$falsy is of type this<Innmind\Immutable\Set>, but the function expects a object<Innmind\Immutable\S>.

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

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

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

function acceptsInteger($int) { }

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

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
271
    }
272
273
    /**
274
     * {@inheritdoc}
275
     */
276 2
    public function join(string $separator): Str
277
    {
278 2
        return $this->values->join($separator);
279
    }
280
281
    /**
282
     * {@inheritdoc}
283
     */
284 2
    public function sort(callable $function): StreamInterface
285
    {
286 2
        return $this->values->sort($function);
287
    }
288
289
    /**
290
     * {@inheritdoc}
291
     */
292 4
    public function merge(SetInterface $set): SetInterface
293
    {
294 4
        $this->validate($set);
295
296 2
        return $set->reduce(
297
            $this,
298 2
            function(self $carry, $value): self {
299 2
                return $carry->add($value);
300 2
            }
301
        );
302
    }
303
304
    /**
305
     * {@inheritdoc}
306
     */
307 20
    public function reduce($carry, callable $reducer)
308
    {
309 20
        return $this->values->reduce($carry, $reducer);
310
    }
311
312
    /**
313
     * {@inheritdoc}
314
     */
315 8
    public function clear(): SetInterface
316
    {
317 8
        $self = clone $this;
318 8
        $self->values = $this->values->clear();
319
320 8
        return $self;
1 ignored issue
show
Bug Best Practice introduced by
The return type of return $self; (Innmind\Immutable\Set) is incompatible with the return type declared by the interface Innmind\Immutable\SetInterface::clear of type self.

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...
321
    }
322
323
    /**
324
     * Make sure the set is compatible with the current one
325
     *
326
     * @param SetInterface $set
327
     *
328
     * @throws InvalidArgumentException
329
     *
330
     * @return void
331
     */
332 22
    private function validate(SetInterface $set)
333
    {
334 22
        if (!$set->type()->equals($this->type)) {
0 ignored issues
show
Documentation introduced by
$this->type is of type object<Innmind\Immutable\Str>, but the function expects a object<self>.

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

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

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

function acceptsInteger($int) { }

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

// Instead of
acceptsInteger($x);

// we recommend to use
acceptsInteger((integer) $x);
Loading history...
335 8
            throw new InvalidArgumentException(
336 8
                'The 2 sets does not reference the same type'
337
            );
338
        }
339 14
    }
340
}
341