Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93682
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.89 cause and error)
Reply-To: internals@lists.php.net
References: <CY1PR0201MB1786C24A2569B71BB6C716FBBF470@CY1PR0201MB1786.namprd02.prod.outlook.com>
 <1228b754-6687-bba2-d251-a8d8586ac107@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
Message-ID: <ef457072-d887-47e9-b7c6-ca94042509e5@fleshgrinder.com>
Date: Wed, 1 Jun 2016 19:30:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <1228b754-6687-bba2-d251-a8d8586ac107@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="P6Clg9L2AwAXojPCgiGnWSf0TVncfaWmF"
Subject: Re: [PHP-DEV] [RFC] Replace "Missing argument" warning with "Too few
 arguments" exception
From: php@fleshgrinder.com (Fleshgrinder)

--P6Clg9L2AwAXojPCgiGnWSf0TVncfaWmF
Content-Type: multipart/mixed; boundary="C8Uktr0R8OOfQpGvbpWN1bPgeQOsqKwiC"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
Message-ID: <ef457072-d887-47e9-b7c6-ca94042509e5@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC] Replace "Missing argument" warning with "Too few
 arguments" exception
References: <CY1PR0201MB1786C24A2569B71BB6C716FBBF470@CY1PR0201MB1786.namprd02.prod.outlook.com>
 <1228b754-6687-bba2-d251-a8d8586ac107@gmail.com>
In-Reply-To: <1228b754-6687-bba2-d251-a8d8586ac107@gmail.com>

--C8Uktr0R8OOfQpGvbpWN1bPgeQOsqKwiC
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 6/1/2016 1:33 PM, Rowan Collins wrote:
> I like the concept behind this, but I worry it might have a rather larg=
e
> BC impact. Like removing call-time pass-by-reference, there may be a lo=
t
> of long-untouched code that needs fixing to work within this constraint=
=2E
> I'm not even sure how easy it would be for static analysis to identify
> these cases. I guess on the flip-side, people will *probably* have
> Warnings displayed or logged already...
>=20
> The RFC would also benefit from more discussion of the current behaviou=
r
> in different cases:
>=20
> function foo($a) {}
> foo(); // Warning
>=20
> function bar(A $a) {}
> bar(); // Error
>=20
> function baz(A $a=3Dnull) {}
> baz(); // OK
>=20
> function quux(?A $a) {}
> quux(); // Not sure. Error?
>=20
> function wibble(int $a) {}
> wibble(); // Error (regardless of strict_types, I think)
>=20
> function wobble(?int $a) {}
> wobble(); // Error?
>=20
> Any other cases?
>=20
> Certainly, making these consistent would be nice, but like a lot of
> consistency, does it come at too high a price?
>=20

I fully agree with Rowan here. First we need a proper plan for all these
cases and a consistent behavior. Next we need to discuss if something
like this can be introduced in a feature release or requires a major
release.

Note that func_get_args() should die too since we have variadic
arguments now. However, this can only be introduced in a major version.
(Correct me if I am wrong and didn't thought of a very common use case
that requires func_get_args(). I for one never need it.)

Whether references need to die completely or not is a more complicated
discussion. There are valid use cases for them. However, they should be
avoided and other solutions should be preferred if possible.

--=20
Richard "Fleshgrinder" Fussenegger


--C8Uktr0R8OOfQpGvbpWN1bPgeQOsqKwiC--

--P6Clg9L2AwAXojPCgiGnWSf0TVncfaWmF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXTxuzAAoJEOKkKcqFPVVrJpIP/1PxDuml7W/IskrDCqI8tG2+
WYPCx6Fk7zQ9MK+WpIEZNp0q3mRsMDWRpZzsRB3kIQETO22pGmcIJ//WrIGZDMzo
fXupN6FWD3e1W4iDhbiJZwJXyVNPXw/q8YiiM9Pm3F8BK2FjyjHEhP/rk23Oqmj6
yCPiCpG6Rck1FT8OpPwz/sdmCGo/HN8kPJDB2xGufG3OxLAXz50U7NbbKfF/pKs2
HiZX9qxNU6sCpMIEp1Q9JVT739Ujpb42wkcuL9KQ7D22dXnR+9kCCSz7335Y5Ysa
JgTrKL0uxKn+ILEIwBux04mdLC0jJdC28Ytp410raasdgTcipzQ9G/ZTMRBU3jJ4
1QzfTnOFh5N9NXoHnx64YeNbVIorX5+87HN6yrs/hwf+bBsfk8Vv299gDvbHMLGn
RrqEHiGCQT+kApG8Cbqe8CX4GVBbgF+aJJ+TXGZ6N4gos7D3Dg4WrxvXwYd+eJN9
Zg3T5RAWUk1gWn/4M/50lrY0RJHjai4hH4pScziPRODLmeheE77uMDYfpWIYa23T
zy9oNbxy04jeNspbeM0fRTPV1RXdMTRRD3aW+fdAJeyI9D/nrIjv0MPVaejTm5EG
+8YEMAEjyGlKWqEg+Da72EXtraW3IKz1dw0Bj6Ul1ar4H1F21vu7TebqXkr4T+Ue
6Kg7bArsw1Z7/vI+l91z
=xa10
-----END PGP SIGNATURE-----

--P6Clg9L2AwAXojPCgiGnWSf0TVncfaWmF--