Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87751
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Davey Shafik'" <davey@php.net>,
	<internals@lists.php.net>
References: <CANaX5ndkK1O2joJKj5HKh-XxPw3ZHLpdZpKyg_qSZDYiW_szfg@mail.gmail.com>
In-Reply-To: <CANaX5ndkK1O2joJKj5HKh-XxPw3ZHLpdZpKyg_qSZDYiW_szfg@mail.gmail.com>
Date: Fri, 14 Aug 2015 10:42:55 +0200
Message-ID: <003401d0d66d$385af9d0$a910ed70$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQMRFRSX5VL4TX2hWWiGtsXSI+iT/5uKpYiA
Content-Language: en-us
Subject: RE: [PHP-DEV] Warning (5.x) -> TypeError (7) for internal Constructors
From: anatol.php@belski.net ("Anatol Belski")

Hi Davey,

> -----Original Message-----
> From: me@daveyshafik.com [mailto:me@daveyshafik.com] On Behalf Of =
Davey
> Shafik
> Sent: Thursday, August 13, 2015 7:01 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Warning (5.x) -> TypeError (7) for internal =
Constructors
>=20
> Hi,
>=20
> I was trying to come up with an example for the
> https://wiki.php.net/rfc/internal_constructor_behaviour RFC and =
noticed some
> unexpected behavior.
>=20
> Based on one of the examples:
>=20
> <?php
> var_dump(new ReflectionFunction([]));
> ?>
>=20
> In PHP 5.6 it will emit a Warning, and returns a unusable instance of
> ReflectionFunction, the latter of which should be resolved by the RFC =
above.
>=20
> Warning: ReflectionFunction::__construct() expects parameter 1 to be =
string,
> array given
>=20
> In PHP 7b3 (and going back to b1 at least), it now throws a TypeError =
on the mis-
> match. I would expect this behavior in strict type mode, but not by =
default. (see:
> http://3v4l.org/jQQtX). The same if you do new PDO([]); but it would =
have
> returned a null previously.
>=20
> Yes, the result is the same, in both cases, an exception should be =
thrown, but it
> should be Constructor failed (the exact exception seems to change =
depending
> on the class you're instantiating).
>=20
> In some cases, this behavior is as expected:
>=20
> new MessageFormatter('en_US', null);
>=20
> Will result in an IntlException with message "Constructor failed"
>=20
> (see: http://3v4l.org/uAjUr)
>=20
> I discussed this with Anthony and he pointed out this commit by nikic =
as the
> change that introduced this behavior:
> https://github.com/php/php-src/pull/1215
>=20
From what I see in the patch, it is not related to strict mode. It is =
more about unifying places that already throw exceptions with different =
names to look

TypeError: NumberFormatter::__construct() expects parameter 1 to be =
string, array given

So from this POV it is good, IMO. Namely, to know that it is the =
concrete case delivering the concrete exception type instead of abstract =
Exception, IntlException, PharException, etc. The chosen exception class =
name might make you think that it's like enforcing strict mode, but =
that's not the case. Hm, so question is - are exception class names =
really bound to whether strict mode is used or not?

The one with ReflectionFunction you've discovered - yes, that's a BC =
deviation. However fits into the scheme and didn't happen at much =
places. What is more of backward incompatibility is that the old codes =
won't now catch those TypeError as most likely they catch Exception, not =
Error.

From what I've spotted yet, some look like

TypeError: NumberFormatter::__construct() expects at least 2 parameters, =
0 given

that is probably not very logic as it has nothing to do with the =
argument types. So not sure about that. Where TypeError is relatively =
appropriate (but maybe a bit confusing because it is used in the strict =
mode as well) for "expect type X, type Y given", the case "expect X =
params, Y given" could have another error class name.

> I believe that internal functions and methods should only emit a =
warning (as per
> 5.x) for incorrect argument types, unless (1) it's a constructor =
failure, and (2)
> you're not using strict mode.
>=20
About exceptions in the functions - there's another thread. Exceptions =
in objects is quite a ordirary  thing anyway. The tendency is that since =
ZE throws them instead of fatals, the behavior to extend over the whole =
code base. Though it needs quite some serious deliberations which didn't =
any big progress yet. Maybe you could contribute there, too. This =
however has no relation to the strict mode as well.

Regards

Anatol