Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52422
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=ShFcnF3OSYCDCfTaHng0XARQKwddY0mLfLZNkphIhANwbfNztvV4VkCp8pcS+N5kO5
         GHmuf2qr9qy8tn0dSgBW9RUIKkofE1bOIHMEkdjSBXQcTpitcU3mFi/s1BiaysfZPEff
         7YAcYUf4jNFd5dDR3uFd10EMbsvHYkILpwQG4=
MIME-Version: 1.0
Sender: andrewcurioso@gmail.com
In-Reply-To: <BANLkTimBiH35PYUbyxZ_zE5SXQX9XCEB8g@mail.gmail.com>
References: <BANLkTimkMTitkMkJ32B32cwYc_5qpLyRhA@mail.gmail.com>
	<1305570720.1344.535.camel@guybrush>
	<BANLkTi=ai-B0g0zwKbXOEH91r2i3ka5rAQ@mail.gmail.com>
	<BANLkTiku0mU94nf=TOQM5GNrLAvOY9Ky4A@mail.gmail.com>
	<BANLkTim-QFYq6Xcb+Y8h85DCpf1GQQ3EuQ@mail.gmail.com>
	<BANLkTi=r==iYmOuZNMAz0qivX4sCGfextg@mail.gmail.com>
	<4DD17ECD.4070505@sugarcrm.com>
	<BANLkTikBj=bh+R9gntDMbdg8a0Y2FnJrmA@mail.gmail.com>
	<20110516212511.GA13139@crousti>
	<BANLkTimBiH35PYUbyxZ_zE5SXQX9XCEB8g@mail.gmail.com>
Date: Tue, 17 May 2011 08:01:43 -0400
Message-ID: <BANLkTimb_v79eDG1DGT4V8HyH9UADhiBcg@mail.gmail.com>
To: Peter Cowburn <petercowburn@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf307abdf51eecdd04a3778901
Subject: Re: [PHP-DEV] Inconsistencies with constructors in SPL
From: andrew@andrewcurioso.com (Andrew Curioso)

--20cf307abdf51eecdd04a3778901
Content-Type: text/plain; charset=ISO-8859-1

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 <petercowburn@gmail.com>wrote:

> Hi folks,
>
> On 16 May 2011 22:25, Etienne Kneuss <colder@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
>
>

--20cf307abdf51eecdd04a3778901--