Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52420
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=HBVAa2oEuA0IXMkjbqafpXXZ0sBbicwGjCHDCQd7QtF7ZtaRDNuBwZRNOtSlGD7sF4
         XFkzoHuAyUO81ghMqoka/7tlLeqwHg/eUGOoQHr28AZ/rxmlVqdYrX+7vpGG8ySBUOU5
         ckEqARiFH2C1CV8EUWkAOH0cx3guQBUzOzlqY=
MIME-Version: 1.0
In-Reply-To: <20110516212511.GA13139@crousti>
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>
Date: Tue, 17 May 2011 09:39:50 +0100
Message-ID: <BANLkTimBiH35PYUbyxZ_zE5SXQX9XCEB8g@mail.gmail.com>
To: Etienne Kneuss <colder@php.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Inconsistencies with constructors in SPL
From: petercowburn@gmail.com (Peter Cowburn)

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
>
>