Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84506
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com>
Date: Tue, 10 Mar 2015 15:31:05 +0000
Message-ID: <CACwt+Jc04Z6JTLcizP_apkAb0jm-ekC5yaHx-my5J4uMeGLRNQ@mail.gmail.com>
To: marcio3w@gmail.com, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e010d833cd5d0960510f0d65b
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count
From: patrickallaert@php.net (Patrick ALLAERT)
References: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com>

--089e010d833cd5d0960510f0d65b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

Le lun. 2 mars 2015 =C3=A0 00:03, Marcio Almada <marcio.web2@gmail.com> a =
=C3=A9crit :

Hi, internals
>
> I'm moving the "Strict Argument Count" RFC into discussion phase:
>
> RFC: https://wiki.php.net/rfc/strict_argcount
> PR: https://github.com/php/php-src/pull/1108
>
> Many different opinions were collected during research phase and the RFC
> was updated with real BC break measurements and other important sections.
> So, before discussing:
>
>    - Even if you already read the RFC in the past, read it again now.
>    - Don't claim **possible** massive BC breaks before read the
>    measurements already done. No matter how seasoned you are with PHP, re=
al
>    numbers matter most than assumptions. Your measurements are welcome to=
o.
>    - Try the patch. Really.
>    - Consider reading the use case present on this post: goo.gl/3ykdIy
>    - Keep discussion on topic and remember we are all trying to improve P=
HP
>    in some way :)
>
> Thanks,
> M=C3=A1rcio
>

 I'm globally +0.5, however I have some concerns:

What about constructors?

Children classes may have a bigger number of arguments for their ctors than
their parents. Even if not very elegant, it is possible some are passing a
fixed number of arguments while constructing an object, whether that object
will take it into account or not.

Something like:

class A {
    function __construct($a)
}

class B extends A {
    function __construct($a, $b)
}

$kind =3D $bool ? "A" : "B";

$object =3D new $kind($foo, $bar);

Why aren't you using E_NOTICE?

[1]: Run-time notices. Indicate that the script encountered something that
could indicate an error, but could also happen in the normal course of
running a script.

E_DEPRECATED:
-1, what is E_DEPRECATED is supposed to be removed in a future version. And
that is a huge BC break if it happens. Btw, you're not mentioning in which
version of PHP the support of extra parameters would be removed.

E_WARNING:
-1, IMHO, calling functions/methods with more arguments generally has less
impact than other aspects that currently generate E_NOTICES (e.g. using
undefined variables, constants,...). Using an error reporting level
stronger than for those cases looks inconsistent.

Cheers and thanks for the impressive work so far!

Patrick

[1] http://php.net/manual/en/errorfunc.constants.php

--089e010d833cd5d0960510f0d65b--