>From what I can tell, whatever changes made to fix this bug, are independent of #54384. Bug #54384 happens when the parent ctor is not called. This bug is triggered only when it is called. I did a quick check of the code and that seems to be the case.
But the existence of that bug makes me think that having a __construct on all SPL classes will be less confusing to the user. So, on that note, back to square one. We can either: - Implement a global SPL noop constructor to be added to all SPL classes that don't have a constructor. - Change the documentation to reflect that some class don't have constructors. Leave the code unchanged but inconsistent. I already have the code for the first option done (just not checked in) and that seems to be where most people are leaning anyway. I can just check that in, close bug #54631 as "Fixed in SVN and needs to be documented" and call it a day. Then we can save the giant roadmap altering discussions about global implicit __construct and/or global parent object for another day. Any objections? - Andrew On Tue, May 17, 2011 at 4:39 AM, Peter Cowburn <petercowb...@gmail.com>wrote: > Hi folks, > > On 16 May 2011 22:25, Etienne Kneuss <col...@php.net> wrote: > > Hi, > > > > On May 16 16:52:08, Andrew Curioso wrote: > >> Well, that wasn't where I was expecting that thread to go, but to wrap > it up > >> what do you think... > >> Is it too late to put this on the 5.4 roadmap for consideration? > >> > >> I'm assuming just the implicit ctor and dtor. Not all magic methods (not > >> now, at least). > >> > >> With your OK, Stas, I'd like to write up an RFC and put it on the Wiki. > >> > >> - Andrew > > > > The main problem with internal classes and ctors is that constructor > > code can be placed at object init instead of in the actual ctor method. > > It is actually safer to place it at object init, because then that code > > is always executed and thus the internal object is not in a half > > initialized state if the user overwrites the constructor and doesn't > > call the parent. > > > > I'd rather have ctors/dtors explicitely defined in SPL. If they are > > documented to exist, they should be explicitely defined. We can define > > such NOOP methods globally, so that it is easy for internal classes to > add > > them. > > This. In the short term, regardless of what happens with the code, > the documentation should reflect what is available in the language. If > a constructor is documented but not available to call then the > documentation needs to be clear about that. Any instances of this > currently in the docs should be a bug, it's an idea to report them > onto the bugs system. > > As for what changes in the code, I think it would be nice for all > (SPL) classes to have a (global, noop) constructor even if nothing of > interest happens within it so that userland developers can happily, > blindly, call the parent constructor in their classes. > > As an aside, do the changes made against #54384 have any impact here? > > > > > As far as implicitly ignore of the constructor, I believe we have enough > > magic regarding ctors/dtors in the engine as it is. > > > > Best, > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
