Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84113
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.160.178 cause and error)
MIME-Version: 1.0
In-Reply-To: <54F35C0F.4090905@mabe.berlin>
References: <CA+kxMuQP76wjEAx8U1JL=VLi-mdrmEwfX_0DDqDibTHZwpqDyg@mail.gmail.com>
	<54F35C0F.4090905@mabe.berlin>
Date: Sun, 1 Mar 2015 19:04:20 +0000
Message-ID: <CA+kxMuSxGBFe++bXcf4VNsNJec_uqY-N5kWfBbr6VQPOQJpEuQ@mail.gmail.com>
To: Marc Bennewitz <dev@mabe.berlin>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes
From: danack@basereality.com (Dan Ackroyd)

On 1 March 2015 at 18:35, Marc Bennewitz <dev@mabe.berlin> wrote:
> What are the reasons to not make this class instantiable / extendable ?

That class handles database state / resources that are not exposed
through the userland classes. It's correct in my opinion for it to not
be extendible or instantiable. Obviously it would be awesome if they
were covered by an interface, to allow testign to be easier, but
that's a separate issue.

> That's definitely better but it's an behavior not possible to implemented in
> user land code as it would be impossible to get such an object.

The same behaviour can seen with the code below.

cheers
Dan

class Foo {

    private static $internalConstruction = false;

    public function __construct() {
        $constructionAllowed = !self::$internalConstruction;
        self::$internalConstruction = false;

        if ($constructionAllowed == false) {
            throw new \Exception("External construction not allowed");
        }
    }

    public static function create() {
        self::$internalConstruction = true;
        return new self();
    }
}

$foo = Foo::create();
var_dump($foo);
$bar = new Foo();