Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67509
Return-Path: <swhitemanlistens-software@cypressintegrated.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 6405 invoked from network); 25 May 2013 04:54:14 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 25 May 2013 04:54:14 -0000
Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender)
X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com
X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)
Received: from [173.1.104.101] ([173.1.104.101:50526] helo=rproxy2-b-iv.figureone.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 81/C6-64297-4F340A15 for <internals@lists.php.net>; Sat, 25 May 2013 00:54:13 -0400
Received: from localhost ([216.220.114.66])
        by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id KJB42010
        for <internals@lists.php.net>; Fri, 24 May 2013 21:54:10 -0700
Date: Sat, 25 May 2013 00:53:29 -0400
Reply-To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
X-Priority: 3 (Normal)
Message-ID: <847803070.20130525005329@cypressintegrated.com>
To: Etienne Kneuss <internals@lists.php.net>
In-Reply-To: <CACQesk4b+-xdXJ66naKKBh6PcN8M2GaDjyFmqwq_yKXqZa7rmg@mail.gmail.com>
References: <6b642a96e673c29dbaf2f239be15f7f6.squirrel@www.l-i-e.com> <519E8ADB.90202@sugarcrm.com> <CAH-PCH6F-upB9tbRotx5YGE4vyZwi0yi5+gOgs9QV3vu8KZryw@mail.gmail.com> <CAKUjMCXMTRvzJUFKFfbz3xV_E2gZ893CDNXjGbuoaKeuJbq2Rw@mail.gmail.com> <CAH-PCH5DGWSmfCjTJdaJtNS4+1N=hM12bGb8eGSuGuhRkmM58w@mail.gmail.com> <CACQesk4b+-xdXJ66naKKBh6PcN8M2GaDjyFmqwq_yKXqZa7rmg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Cannot call constructor
From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman)

Encouraging call super is still not the right way to go about this. As
I said before, even with the changes proposed, there's no way to
*contractually enforce* the call super pattern in this language.
That's why it is and will remain an antipattern. So all you're doing
is allowing people to more easily use the antipattern, instead of (a)
baking auto-super (contractual call super) into the language or (b)
pushing people to use a preferred pattern (Template Method or other).

Template Method in userland is not difficult (lightly tested):
        
        trait templateInitializer {
                private $inited;
                final public function __construct( $arg1, $arg2 ) {
                        print "__construct in super calling inits...<BR>";
                        $this->init( $arg1, $arg2 );
                        $this->inited or self::init( $arg1, $arg2 );
                }
                protected function init ( $arg1, $arg2 ) { print "init in super...<BR>"; $this->inited = true; }
        }
        
        class superClass3 {
                use templateInitializer;
        }
        
        class subClass3a extends superClass3 {
                protected function init ( $arg1, $arg2 ) { print "init in sub...<BR>"; }
        }
        
        class subClass3b extends superClass3 {}
        
        class subSubClass3a1 extends subClass3a {
                protected function init ( $arg1, $arg2 ) { print "init in sub-sub...<BR>"; }
        }

        new superClass3 ( null, null ); // runs root init
        new subClass3a ( null, null ); // runs child init, then root
        new subClass3b ( null, null ); // runs root init
        new subSubClass3a1 (null, null); // runs grandchild, then root

You can extend this model to preInit() and postInit() methods, giving
even more flexibility. And in none of these cases does the subclass
need to "remember" to do anything.

This thread arose in response to what is undeniably a bad API
authoring practice (first allowing full ctor override and later
breaking BC without fanfare). Why are we letting the authors of
Richard's library off the hook and putting it on ourselves to develop
hacks? They obviously screwed up. What next? Do we let API consumers
override a `final` that they don't like? Just use the right pattern in
the first place. IMO.

-- S.