Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67477
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender)
Date: Fri, 24 May 2013 00:29:20 -0400
Reply-To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Message-ID: <271053872.20130524002920@cypressintegrated.com>
To: "Richard Lynch" <internals@lists.php.net>
In-Reply-To: <6b642a96e673c29dbaf2f239be15f7f6.squirrel@www.l-i-e.com>
References: <6b642a96e673c29dbaf2f239be15f7f6.squirrel@www.l-i-e.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)

> I use some OOP library, that is a "black box" and I like it that way.

Hmm, there's "well-documented, change-controlled, trustable API that
you shouldn't try to work around" and then there's "black box." I'm
not sure the latter ever sounds like a good thing... I've always used
it as a bad word.

> Suddenly my code doesn't work. Maybe the resource is only needed under
> certain conditions. So their __construct doesn't get called, but
> nothing bad happens until the circumstances where they need the
> __construct called.

If their __construct suddenly becomes mandatory, they are deprecating
something they (I presume explicitly) supported in the past: ctor
overrides without call super.

So either they put this in giant blinking text in their UPDATING file
and you missed it, or they broke backward compatibility and didn't
know it or didn't care.

If I were faced with their situation, I'd make the ctor final to make
damn sure you realized something was wrong. Then I would say
overriding __construct is no longer supported because continuing to
support it means mandating call super, which is an impossible contract
for the language (this anguage) to enforce. I would abstract the whole
thing out to an initChild() type pattern and so on. If you have to
change your code, them's the breaks, as long as they give a clear
path.

I don't think the solution is to work around such mistakes on the part
of a lib developer by silencing (?) calls to a nonexistent method _in
addition to_ mandating call super -- IMO, that's even smellier than
call super on its own. Why not add auto-super contracts to PHP instead
(which would include skipping nonexistent super methods)?

Making the undefined method error catchable instead of fatal I agree
with, though. More like the more catchable world of Reflection.

-- Sandy