Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84591
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.51 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <CACwt+JdSGZORCFpft58nnVynx=eF_b0xe7MXo=AgkK4NXN-JKA@mail.gmail.com>
References: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com>
 <CACwt+Jc04Z6JTLcizP_apkAb0jm-ekC5yaHx-my5J4uMeGLRNQ@mail.gmail.com>
 <CAOsHV+vamXYYoBRPpWgGx2piDxBW16cFX=F0KM0A9msrr2YUcw@mail.gmail.com> <CACwt+JdSGZORCFpft58nnVynx=eF_b0xe7MXo=AgkK4NXN-JKA@mail.gmail.com>
Date: Wed, 11 Mar 2015 19:30:40 -0300
Message-ID: <CAOsHV+te91JwVfsqKP80F8G0vEgm5Hc18sVhDR29c_57zmNq-w@mail.gmail.com>
To: Patrick ALLAERT <patrickallaert@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c341ac6c014405110ad2e0
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count
From: marcio.web2@gmail.com (Marcio Almada)

--001a11c341ac6c014405110ad2e0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi

2015-03-11 6:50 GMT-03:00 Patrick ALLAERT <patrickallaert@php.net>:

> Le mar. 10 mars 2015 =C3=A0 21:04, Marcio Almada <marcio.web2@gmail.com> =
a
> =C3=A9crit :
>
>>
>>
>> 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? [...]
>>>
>> 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 y=
ou
>>> have a deeper point on it though as PHP is a weirdo and allows construc=
tors
>>> on interfaces.
>>>
>>> Also, FYI, before we reach discussion phase, there was an idea to ignor=
e
>>> 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 othe=
r
>>> than *__call* and *__callStatic* for now.
>>>
>>
> No deep point, just wanted to bring your attention on it.
>
>>
>>
>>> 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 lev=
el
>>> stronger than for those cases looks inconsistent.
>>>
>>
>> I disagree with the "looks inconsistent" part. The E_WARNING option woul=
d
>> 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 ev=
en
>> more dangerous than a missing argument.
>>
>
> You have a (debatable) point :)
>
> It depends according to what aspect of PHP your are comparing it with.
> Greping zend_error(E_NOTICE,.*) in the code I had the feeling that alread=
y
> many notices where the sign of a bigger problem than when passing extra
> parameters, hence why I suggested E_NOTICE.
>
> My consistency argument was therefore "severity based".
>

Ok, that's a good POV. It just turns out that the severity may vary from
case to case.


> 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.
>>
>
> I wouldn't -1 for E_WARNING because of your extra arguments (sorry for th=
e
> pun ;), someone had to do it!). Still in favor of E_NOTICE though.
>
>
That's great to know. Looks like E_WARNING vs E_NOTICE vs E_STRICT seems to
be good setup even though I still don't like to have 3 options though.


> Patrick
>

Thanks,
M=C3=A1rcio

--001a11c341ac6c014405110ad2e0--