# Exception throwed if parent::__construct() not called in \DirectoryIterator subclass - Thread: https://externals.io/message/54227 - Original archive: https://news-web.php.net/php.internals/54227 - Started by frederic.hardy@mageekbox.net on 2011-07-28T09:57:32+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #54227 — frederic.hardy@mageekbox.net — 2011-07-28T09:57:32+00:00 URL: https://externals.io/message/54227#54227 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 be 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 new behavior, because moked \DirectoryIterator class does not call the parent constructor. In context of unit test, the fact that \DirectoryIterator is inconsistant may be not a problem and can be the desired behavior. There is a bug report : https://bugs.php.net/bug.php?id=55300 Best regards, Fred -- ======================================================================== Frédéric Hardy : Architecte d'application/Admin. système/Ergonome CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf Blog : http://blog.mageekbox.net Twitter : http://twitter.com/mageekguy ======================================================================== --- ## #54235 — Etienne Kneuss — 2011-07-28T18:25:20+00:00 URL: https://externals.io/message/54227#54235 · In reply to: #54227 Hello, 2011/7/28 Frédéric Hardy : > 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 be 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 new > behavior, because moked \DirectoryIterator class does not call the parent > constructor. > In context of unit test, the fact that \DirectoryIterator is inconsistant > may be not a problem and can be the desired behavior. We have two ways internally of execute code that needs to be executed as soon as we instantiate the object: 1) In the constructor 2) In the handler managing instantiation. Doing it in (1) is problematic as PHP gives no implicit guarantee that it will be called. Doing it in (2) is also problematic as it makes the class "magic", by putting code with effects in a place where it doesn't belong. From a design perspective it is better to execute such code in the constructor, especially if it takes argument, so (1) is "more correct" than (2). Now, as I said, PHP does not force you to call the parent constructor. In almost every cases, not calling the overridden constructor is bad practice and yields inconsistent results. For internal classes, skipping code that often do mostly initialization is dangerous and leads to crashes. Now, for the issue at hand: Even though it is a BC break, I believe that it is a very small one and that it should be seen as a bug fix. Note that the restriction is only here if the user tries to do something terribly wrong. IMO, it should remain impossible to extend DirectoryIterator's __construct without calling the parent construct. Best, > > There is a bug report : https://bugs.php.net/bug.php?id=55300 > > Best regards, > Fred > -- > > ======================================================================== > Frédéric Hardy : Architecte d'application/Admin. système/Ergonome >           CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf >         Blog : http://blog.mageekbox.net >      Twitter : http://twitter.com/mageekguy > ======================================================================== > > > -- > > > > -- Etienne Kneuss http://www.colder.ch --- ## #54236 — John Crenshaw — 2011-07-28T19:36:33+00:00 URL: https://externals.io/message/54227#54236 · In reply to: #54235 2011/7/28 Frédéric Hardy : > 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 be 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 new > behavior, because moked \DirectoryIterator class does not call the parent > constructor. > In context of unit test, the fact that \DirectoryIterator is inconsistant > may be not a problem and can be the desired behavior. I strongly agree. Throwing an exception ONLY because the parent constructor wasn't called is a serious departure from expectations. It is fine for other code in the parent class to fail later due to incomplete/improper initialization which may likely be caused by failure to call the parent constructor earlier, (In fact, that is even expected in many cases) but I cannot conceive of any acceptable reason for the error described here. Even though the change was certainly well intentioned, it clearly didn't account for the possibility of unusual but valid coding situations (such as mocks and other code generation tactics that should be able to reasonably depend on consistent language behaviors). John Crenshaw Priacta, Inc. --- ## #54237 — Richard Quadling — 2011-07-28T20:08:47+00:00 URL: https://externals.io/message/54227#54237 · In reply to: #54236 > > > 2011/7/28 Frédéric Hardy : > > […] > > I strongly agree. Throwing an exception ONLY because the parent constructor wasn't called is a serious departure from expectations. It is fine for other code in the parent class to fail later due to incomplete/improper initialization which may likely be caused by failure to call the parent constructor earlier, (In fact, that is even expected in many cases) but I cannot conceive of any acceptable reason for the error described here. Even though the change was certainly well intentioned, it clearly didn't account for the possibility of unusual but valid coding situations (such as mocks and other code generation tactics that should be able to reasonably depend on consistent 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. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea