Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84114 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51457 invoked from network); 1 Mar 2015 19:28:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Mar 2015 19:28:48 -0000 Authentication-Results: pb1.pair.com header.from=dev@mabe.berlin; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=dev@mabe.berlin; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error) X-PHP-List-Original-Sender: dev@mabe.berlin X-Host-Fingerprint: 80.237.132.167 wp160.webpack.hosteurope.de Received: from [80.237.132.167] ([80.237.132.167:60166] helo=wp160.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4E/31-42670-07863F45 for ; Sun, 01 Mar 2015 14:28:48 -0500 Received: from dslb-188-102-024-210.188.102.pools.vodafone-ip.de ([188.102.24.210] helo=[192.168.178.30]); authenticated by wp160.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1YS9Xh-0003VD-9r; Sun, 01 Mar 2015 20:28:45 +0100 Message-ID: <54F3686C.3010709@mabe.berlin> Date: Sun, 01 Mar 2015 20:28:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dan Ackroyd CC: "internals@lists.php.net" References: <54F35C0F.4090905@mabe.berlin> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;dev@mabe.berlin;1425238128;bbc09d43; Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes From: dev@mabe.berlin (Marc Bennewitz) Am 01.03.2015 um 20:04 schrieb Dan Ackroyd: > On 1 March 2015 at 18:35, Marc Bennewitz 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(); > OK you are right but it's ugly code and the not callable constructor needs to be documented as it's not visible without calling. The following would be the standard way to go: final class PDORow { private function __construct() { // ... } public static function create() { return new self(); } } Marc