For compatibility and reusability of your code, PSR1 recommends that a file should introduce either new symbols (like classes, functions, etc.) or have side-effects (like outputting something, or including other files), but not both at the same time. The first symbol is defined on line 17 and the first side effect is on line 7.
The PSR-1: Basic Coding Standard recommends that a file should either introduce
new symbols, that is classes, functions, constants or similar, or have side effects.
Side effects are anything that executes logic, like for example printing output,
changing ini settings or writing to a file.
The idea behind this recommendation is that merely auto-loading a class should not change the state
of an application. It also promotes a cleaner style of programming and makes your code
less prone to errors, because the logic is not spread out all over the place.
To learn more about the PSR-1, please see the PHP-FIG site on the
PSR-1.
Loading history...
2
3
namespace SMW\ApprovedRevs\PropertyAnnotators;
4
5
use SMW\DIProperty;
6
use SMW\SemanticData;
7
use SMWDITime as DITime;;
8
use SMW\ApprovedRevs\DatabaseLogReader;
9
use SMW\ApprovedRevs\PropertyRegistry;
10
use User;
11
12
/**
13
* @private
14
*
15
* @license GNU GPL v2+
16
*/
17
class ApprovedDatePropertyAnnotator {
18
19
/**
20
* @var DatabaseLogReader
21
*/
22
private $databaseLogReader;
23
24
/**
25
* @var Integer|null
26
*/
27
private $approvedDate;
28
29
/**
30
* @param DatabaseLogReader $databaseLogReader
31
*/
32
3
public function __construct( DatabaseLogReader $databaseLogReader ) {
33
3
$this->databaseLogReader = $databaseLogReader;
34
3
}
35
36
/**
37
* @since 1.0
38
*
39
* @param integer $approvedDate
40
*/
41
2
public function setApprovedDate( $approvedDate ) {
42
2
$this->approvedDate = $approvedDate;
43
2
}
44
45
/**
46
* @since 1.0
47
*
48
* @return DIProperty
49
*/
50
2
public function newDIProperty() {
51
2
return new DIProperty( PropertyRegistry::SAR_PROP_APPROVED_DATE );
52
}
53
54
/**
55
* @since 1.0
56
*
57
* @param SemanticData $semanticData
58
*/
59
2
public function addAnnotation( SemanticData $semanticData ) {
It seems like $this->databaseLogReader...getTitle(), 'approval') can also be of type object<MWTimestamp>. However, the property $approvedDate is declared as type integer|null. Maybe add an additional type check?
Our type inference engine has found a suspicous assignment of a value to a property.
This check raises an issue when a value that can be of a mixed type is assigned to
a property that is type hinted more strictly.
For example, imagine you have a variable $accountId that can either hold an
Id object or false (if there is no account id yet). Your code now assigns that
value to the id property of an instance of the Account class. This class
holds a proper account, so the id value must no longer be false.
Either this assignment is in error or a type check should be added for that assignment.
classId{public$id;publicfunction__construct($id){$this->id=$id;}}classAccount{/** @var Id $id */public$id;}$account_id=false;if(starsAreRight()){$account_id=newId(42);}$account=newAccount();if($accountinstanceofId){$account->id=$account_id;}
SemanticMediaWiki /
SemanticApprovedRevs
Loading history...
The PSR-1: Basic Coding Standard recommends that a file should either introduce new symbols, that is classes, functions, constants or similar, or have side effects. Side effects are anything that executes logic, like for example printing output, changing ini settings or writing to a file.
The idea behind this recommendation is that merely auto-loading a class should not change the state of an application. It also promotes a cleaner style of programming and makes your code less prone to errors, because the logic is not spread out all over the place.
To learn more about the PSR-1, please see the PHP-FIG site on the PSR-1.