Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80697
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain tekwire.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@tekwire.net>
To: "'Dan Ackroyd'" <danack@basereality.com>,
	<internals@lists.php.net>
References: <CA+kxMuQcfMY00k+WtnNUppD7N9PMQsx356h1XTy1X8px1m0MBw@mail.gmail.com>
In-Reply-To: <CA+kxMuQcfMY00k+WtnNUppD7N9PMQsx356h1XTy1X8px1m0MBw@mail.gmail.com>
Date: Sat, 17 Jan 2015 16:37:00 +0100
Message-ID: <003201d0326b$6fd27f60$4f777e20$@tekwire.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQFhYE8a1kvkTW+sIcCGIio0m9gpNZ2iDSSQ
Content-Language: fr
Subject: RE: [PHP-DEV] Class constructor behaviour
From: francois@tekwire.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : Dan Ackroyd [mailto:danack@basereality.com]
>
> This is pretty horrible and should be fixed by making sure that
> constructors either return an object or throw an exception.
> Additionally the exception policy for core (that was previously
> discussed here: http://marc.info/?t=3D119263748000001&r=3D1&w=3D2 ) =
should
> be updated so that any constructor returning NULL is considered a bug,
> no matter what the ini settings are.

I would prefer deciding that returning null is the standard way for a =
constructor to inform the PHP core that the object creation failed (for =
any reason). This would be trapped by the core and cause a catchable =
fatal error.

This is more compatible with the 'exception-less' behavior of the core =
in general. The constructor is still free to throw an exception but this =
wouldn't be encouraged nor the standard way to inform the core that an =
error occurred.

It also allows for minimal code changes. This could be split in two =
steps. First, the core is modified to trap null return values from =
constructors. Then, class constructors who did implement another =
mechanism can be modified one by one. I think that it is also better for =
PECL extensions as, if we don't introduce the check in the core, it is =
just a convention that extension developers *should* follow. BC break =
would be minimal too (would only impact for few programs who had ways to =
manage null return values from constructors).

> Constructors give warning, but are then in an unusable state
> -----------------------

Same, should return null and not create object.

> Constructor gives error
> -----------------------

Should return null, and the core would raise the error. No BC break here =
(except loosing a possible explanation in error message, but is it a BC =
break ?)

> These changes would need an RFC to be approved I presume. However
> doing the RFC would probably require making a patch that implements
> most, if not all, of these changes.

IMO, you should write the RFC, as it would be quite fast (even if you =
forget to list some classes). Please mention at least your option and =
mine.

On such a subject, I wouldn't implement anything before approval, even a =
non-official one. We don't need a POC here, as everybody clearly sees =
the impact the change would have.

Cheers

Fran=C3=A7ois