Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84517
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.44 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <CACwt+Jc04Z6JTLcizP_apkAb0jm-ekC5yaHx-my5J4uMeGLRNQ@mail.gmail.com>
References: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com>
 <CACwt+Jc04Z6JTLcizP_apkAb0jm-ekC5yaHx-my5J4uMeGLRNQ@mail.gmail.com>
Date: Tue, 10 Mar 2015 17:04:18 -0300
Message-ID: <CAOsHV+vamXYYoBRPpWgGx2piDxBW16cFX=F0KM0A9msrr2YUcw@mail.gmail.com>
To: Patrick ALLAERT <patrickallaert@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c355761f1dc90510f4a90a
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count
From: marcio.web2@gmail.com (Marcio Almada)

--001a11c355761f1dc90510f4a90a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015-03-10 12:31 GMT-03:00 Patrick ALLAERT <patrickallaert@php.net>:

> Hello,
>
> Le lun. 2 mars 2015 =C3=A0 00:03, Marcio Almada <marcio.web2@gmail.com> a
> =C3=A9crit :
>
>
>  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);
>

I think this is somehow covered here
https://wiki.php.net/rfc/strict_argcount#hassle_factor, the example is not
explicit to ctors but the same principles seem to apply. Not sure you have
a deeper point on it though as PHP is a weirdo and allows constructors on
interfaces.

Also, FYI, before we reach discussion phase, there was an idea to ignore
ctors and other magic methods but you are the first person to bring it up
on the ML. I'm not very inclined to ignore any other magic methods other
than *__call* and *__callStatic* for now.


>
> Why aren't you using E_NOTICE?
>

> [1]: Run-time notices. Indicate that the script encountered something tha=
t
> could indicate an error, but could also happen in the normal course of
> running a script.
>
>
I have nothing against E_NOTICE in this case and indeed E_NOTICE seems like
a good fit. I'll add it as an option.


> 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.
>
>
I was sympathetic towards E_DEPRECATED in the early stage of discussion
phase but I'm not anymore. If somebody would like to E_DEPRECATE something
related to argument count in the future, the this person will have to
create another RFC and start the deprecation on PHP 7.1. I'm removing this
option now :)


> E_WARNING:
> -1, IMHO, calling functions/methods with more arguments generally has les=
s
> 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.
>
>
I disagree with the "looks inconsistent" part. The E_WARNING option would
actually be the most consistent with current PHP behavior. Ex:

function fn($a, $b){}
fn(1);
PHP warning:  Missing argument 2 for fn(), called in...

If we choose E_WARNING both minimum and maximum argument count will have
the same error level. BTW, in some cases an exceeding argument can be even
more dangerous than a missing argument.

I have no strong feelings regarding to the error level, the E_WARNING vs
E_NOTICE seems legit so I'm waiting for more opinions.

Cheers and thanks for the impressive work so far!
>
> Patrick
>
> [1] http://php.net/manual/en/errorfunc.constants.php
>

You're welcome. Thanks for the useful feedback. Hope we can reach a
consensus on the options before the voting starts.

M=C3=A1rcio.

--001a11c355761f1dc90510f4a90a--