BaseModel::asDateTime() - Code Metrics - Inspection of "WIP updated to functional component, refactored fu..." - GCTC-NTGC/TalentCloud - Measure and Improve Code Quality continuously with Scrutinizer

Test Setup Failed

Push — feature/word_counter ( e4aaca...45e6a8 )

by Yonathan

created 2019-07-31 19:14 UTC

BaseModel::asDateTime() B

↳ Parent: Project

Complexity

Conditions	6
Paths	6

Size

Total Lines

Duplication

Lines	0
Ratio	0 %

Code Coverage

Tests	12
CRAP Score	6.105

Importance

Changes

Metric	Value
cc	6
nc	6
nop	1
dl	0
loc	39
ccs	12
cts	14
cp	0.8571
crap	6.105
rs	8.6737
c	0
b	0
f	0

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model as Eloquent;
use Illuminate\Support\Facades\Config;
use Carbon\Carbon;
use DateTimeInterface;
use Jenssegers\Date\Date;

abstract class BaseModel extends Eloquent {
    //Override date functions to return Jenssegers Data instead of Carbon

    /**
     * Get a fresh timestamp for the model.
     *
     * @return Date
     */
    public function freshTimestamp()
    {
        return new Date;
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());
}
    }

    /**
     * Return a timestamp as DateTime object.
     *
     * @param  mixed $value
     * @return Date
     */
    protected function asDateTime($value)
    {
        $timezone = Config::get('app.timezone');

        // If this value is already a Carbon instance, we shall just return it as is.
        // This prevents us having to re-instantiate a Carbon instance when we know
        // it already is one, which wouldn't be fulfilled by the DateTime check.
        if ($value instanceof Carbon) {
            return Date::parse($value, $timezone);
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());
}
        }
        if ($value instanceof Date) {
            return $value;
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());
}
        }
        // If the value is already a DateTime instance, we will just skip the rest of
        // these checks since they will be a waste of time, and hinder performance
        // when checking the field. We will just return the DateTime right away.
        if ($value instanceof DateTimeInterface) {
            return new Date(
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());
}
                //$value->format('Y-m-d H:i:s.u'), $value->getTimeZone()
                $value->format('Y-m-d H:i:s.u'), $timezone
            );
        }
        // If this value is an integer, we will assume it is a UNIX timestamp's value
        // and format a Carbon object from this timestamp. This allows flexibility
        // when defining your date fields as they might be UNIX timestamps here.
        if (is_numeric($value)) {
            return Date::createFromTimestamp($value, $timezone);
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());
}
        }
        // If the value is in simply year, month, day format, we will instantiate the
        // Carbon instances from that format. Again, this provides for simple date
        // fields on the database, while still supporting Carbonized conversion.
        if (preg_match('/^(\d{4})-(\d{1,2})-(\d{1,2})$/', $value)) {
            return Date::createFromFormat('Y-m-d', $value, $timezone)->startOfDay();
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());
}
        }
        // Finally, we will just assume this date is in the format used by default on
        // the database connection and use that format to create the Carbon object
        // that is returned back out to the developers after we convert it here.
        return Date::createFromFormat($this->getDateFormat(), $value, $timezone);
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());
}
    }
}


1		<?php
2
3		namespace App\Models;
4
5		use Illuminate\Database\Eloquent\Model as Eloquent;
6		use Illuminate\Support\Facades\Config;
7		use Carbon\Carbon;
8		use DateTimeInterface;
9		use Jenssegers\Date\Date;
10
11		abstract class BaseModel extends Eloquent {
12		//Override date functions to return Jenssegers Data instead of Carbon
13
14		/**
15		* Get a fresh timestamp for the model.
16		*
17		* @return Date
18		*/
19	55	public function freshTimestamp()
20		{
21	55	return new Date;
		0 ignored issues – show Bug Best Practice introduced 2019-07-09 12:53 UTC by Report Bug Copy Issue Report The return type of `return new \Jenssegers\Date\Date();` (`Jenssegers\Date\Date`) is incompatible with the return type of the parent method `Illuminate\Database\Eloquent\Model::freshTimestamp` of type `Illuminate\Support\Carbon`. 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...
22		}
23
24		/**
25		* Return a timestamp as DateTime object.
26		*
27		* @param mixed $value
28		* @return Date
29		*/
30	55	protected function asDateTime($value)
31		{
32	55	$timezone = Config::get('app.timezone');
33
34		// If this value is already a Carbon instance, we shall just return it as is.
35		// This prevents us having to re-instantiate a Carbon instance when we know
36		// it already is one, which wouldn't be fulfilled by the DateTime check.
37	55	if ($value instanceof Carbon) {
38	55	return Date::parse($value, $timezone);
		0 ignored issues – show Bug Best Practice introduced 2019-07-09 12:53 UTC by Report Bug Copy Issue Report The return type of `return \Jenssegers\Date\...rse($value, $timezone);` (`Jenssegers\Date\Date`) is incompatible with the return type of the parent method `Illuminate\Database\Eloquent\Model::asDateTime` of type `Illuminate\Support\Carbon`. 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	55	if ($value instanceof Date) {
41		return $value;
		0 ignored issues – show Bug Best Practice introduced 2019-07-09 12:53 UTC by Report Bug Copy Issue Report The return type of `return $value;` (`Jenssegers\Date\Date`) is incompatible with the return type of the parent method `Illuminate\Database\Eloquent\Model::asDateTime` of type `Illuminate\Support\Carbon`. 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...
42		}
43		// If the value is already a DateTime instance, we will just skip the rest of
44		// these checks since they will be a waste of time, and hinder performance
45		// when checking the field. We will just return the DateTime right away.
46	55	if ($value instanceof DateTimeInterface) {
47	27	return new Date(
		0 ignored issues – show Bug Best Practice introduced 2019-07-09 12:53 UTC by Report Bug Copy Issue Report The return type of `return new \Jenssegers\D... H:i:s.u'), $timezone);` (`Jenssegers\Date\Date`) is incompatible with the return type of the parent method `Illuminate\Database\Eloquent\Model::asDateTime` of type `Illuminate\Support\Carbon`. 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...
48		//$value->format('Y-m-d H:i:s.u'), $value->getTimeZone()
49	27	$value->format('Y-m-d H:i:s.u'), $timezone
50		);
51		}
52		// If this value is an integer, we will assume it is a UNIX timestamp's value
53		// and format a Carbon object from this timestamp. This allows flexibility
54		// when defining your date fields as they might be UNIX timestamps here.
55	55	if (is_numeric($value)) {
56		return Date::createFromTimestamp($value, $timezone);
		0 ignored issues – show Bug Best Practice introduced 2019-07-09 12:53 UTC by Report Bug Copy Issue Report The return type of `return \Jenssegers\Date\...amp($value, $timezone);` (`Jenssegers\Date\Date`) is incompatible with the return type of the parent method `Illuminate\Database\Eloquent\Model::asDateTime` of type `Illuminate\Support\Carbon`. 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...
57		}
58		// If the value is in simply year, month, day format, we will instantiate the
59		// Carbon instances from that format. Again, this provides for simple date
60		// fields on the database, while still supporting Carbonized conversion.
61	55	if (preg_match('/^(\d{4})-(\d{1,2})-(\d{1,2})$/', $value)) {
62	3	return Date::createFromFormat('Y-m-d', $value, $timezone)->startOfDay();
		0 ignored issues – show Bug Best Practice introduced 2019-07-09 12:53 UTC by Report Bug Copy Issue Report The return type of `return \Jenssegers\Date\...imezone)->startOfDay();` (`Jenssegers\Date\Date`) is incompatible with the return type of the parent method `Illuminate\Database\Eloquent\Model::asDateTime` of type `Illuminate\Support\Carbon`. 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...
63		}
64		// Finally, we will just assume this date is in the format used by default on
65		// the database connection and use that format to create the Carbon object
66		// that is returned back out to the developers after we convert it here.
67	55	return Date::createFromFormat($this->getDateFormat(), $value, $timezone);
		0 ignored issues – show Bug Best Practice introduced 2019-07-09 12:53 UTC by Report Bug Copy Issue Report The return type of `return \Jenssegers\Date\...(), $value, $timezone);` (`Jenssegers\Date\Date`) is incompatible with the return type of the parent method `Illuminate\Database\Eloquent\Model::asDateTime` of type `Illuminate\Support\Carbon`. 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...
68		}
69		}
70

GCTC-NTGC / TalentCloud

Push — feature/word_counter ( e4aaca...45e6a8 )

BaseModel::asDateTime() B

Complexity

Size

Duplication

Code Coverage

Importance

Duplication Side-by-Side

Filter issues like