Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54237
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
Reply-To: RQuadling@GMail.com
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B80604A6A276@MAILR001.mail.lan>
References: <4E31328C.9030208@mageekbox.net> <CACQesk7OiWGkkKzHTY7BYW=LB_ERheVne42EnvpWhUQVqOUdyw@mail.gmail.com>
 <A633CF2D7C7BED41B41F1E64F25507B80604A6A276@MAILR001.mail.lan>
Date: Thu, 28 Jul 2011 21:08:47 +0100
Message-ID: <CAKUjMCWOWbLJXwyJCTztnXsAWT70odOZgbsLxkFS=FaD+1CV3g@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: Etienne Kneuss <colder@php.net>, 
	"frederic.hardy@mageekbox.net" <frederic.hardy@mageekbox.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Exception throwed if parent::__construct() not called
 in \DirectoryIterator subclass
From: rquadling@gmail.com (Richard Quadling)

On 28 July 2011 20:36, John Crenshaw <johncrenshaw@priacta.com> wrote:
>
>
> 2011/7/28 Fr=C3=A9d=C3=A9ric Hardy <frederic.hardy@mageekbox.net>:
>> Hello !
>>
>> In PHP 5.4 alpha, an exception is throwing if a subclass of
>> \DirectoryIterator not called the parent constructor.
>> Moreover, this exception can not be catched in the constructor of the
>> subclass.
>> This behavious seems to be a good idea, because \DirectoryIterator may b=
e in
>> an inconsistant state if the parent constructor is not called.
>> But i think that it's not a good idea, because it's a BC break.
>> It's not the case in 5.3 and i have unit test cases which fail by this n=
ew
>> behavior, because moked \DirectoryIterator class does not call the paren=
t
>> constructor.
>> In context of unit test, the fact that \DirectoryIterator is inconsistan=
t
>> may be not a problem and can be the desired behavior.
>
> I strongly agree. Throwing an exception ONLY because the parent construct=
or wasn't called is a serious departure from expectations. It is fine for o=
ther code in the parent class to fail later due to incomplete/improper init=
ialization which may likely be caused by failure to call the parent constru=
ctor earlier, (In fact, that is even expected in many cases) but I cannot c=
onceive of any acceptable reason for the error described here. Even though =
the change was certainly well intentioned, it clearly didn't account for th=
e possibility of unusual but valid coding situations (such as mocks and oth=
er code generation tactics that should be able to reasonably depend on cons=
istent language behaviors).

If the constructor MUST be called, then it would seem that you must
not be allowed to extend it and instead, have another method which you
must use.

Badly, beforeConstruct() and/or afterConstruct(), but then we are
moving to AOP (which would be nice).

Enforcement of the constructor can only be achieved by making it final.
--=20
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea