Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84942
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAOsHV+shDOuXFxvo29vXAJXVfHRhbotrUaK5EpY3-UWrQy2vrg@mail.gmail.com>
References: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com>
 <54FF8CED.5030701@gmail.com> <CAOsHV+sdkSnrB_ZSHE1T81rnBt1K58-_fOzt6-kjHpghmjV5kA@mail.gmail.com>
 <54FFC96D.6090004@gmail.com> <1579682575.9673.1426064704052.JavaMail.open-xchange@app06.ox.hosteurope.de>
 <55000A88.1030909@lsces.co.uk> <CAOsHV+sZbE3EMvxTe4esXaUebcA+GKnYbDLEdo8ZXXwY6UJBdg@mail.gmail.com>
 <CACwt+Je7mH0YWsFWL9+Lh9=nZmGUn8hRrJGmRk1wHtAnoeEJNQ@mail.gmail.com> <CAOsHV+shDOuXFxvo29vXAJXVfHRhbotrUaK5EpY3-UWrQy2vrg@mail.gmail.com>
Date: Sun, 15 Mar 2015 22:16:02 +0000
Message-ID: <CADyq6sKiHJ5ugvsX7NFTRhFdy6gPLnWoerLiSiQqjUxsypj-9g@mail.gmail.com>
To: marcio3w@gmail.com
Cc: Patrick ALLAERT <patrickallaert@php.net>, Lester Caine <lester@lsces.co.uk>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b86d8b26e4bdd05115b156b
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count
From: ocramius@gmail.com (Marco Pivetta)

--047d7b86d8b26e4bdd05115b156b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Marcio/internals,

I just went through the RFC again (didn't check the discussion since our
last chat about it in Room 11).

The section about '"Flexible" Interface Implementations' mentions the
interface as an 'an acceptable =E2=80=9CPHPism=E2=80=9D'.

This is not just an "acceptable PHPism", it's a "life saving PHPism".

To give you an idea of the amount of code that was saved from a massive
refactoring when ZF1 =3D> ZF2 code was ported by current ZF2 users, think
about all web apps that have form contextual validation.
Guess what? Almost all web applications have forms, and almost all apps
have something like a "confirm password" form.
Yep, *ALL* ZF2 apps are affected by this RFC, and it will likely prevent an
upgrade to PHP7 in the near future unless our users upgrade to ZF3, which
will be PHP 5.5 based, and therefore without variadic arguments.

This is not an interface that I'm proud of, but it is an interface that
saved a lot of time/money to a lot of users, and that allows flexible
handling of contextual validation where we didn't foresee one upfront (the
interface is indeed *wrong*, but we can't fix it in a stable release).

Until all of the framework and all of the users have migrated to variadic
interfaces, this particular RFC is a problem.

Getting this change into PHP7 would mean having a major part of the
framework community having a real hard time in upgrading.

Additionally to all these worries of mine, consider that mistakes like the
one with the `ValidatorInterface` may happen again in the future, and this
"PHPism" is actually saving our asses out there.

Don't get rid of it for the sake of clean code, because these "dirty hacks"
have already proven themselves REALLY useful.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 14 March 2015 at 00:37, Marcio Almada <marcio.web2@gmail.com> wrote:

> Hi
>
> 2015-03-13 6:02 GMT-03:00 Patrick ALLAERT <patrickallaert@php.net>:
>
> > Le mer. 11 mars 2015 =C3=A0 22:44, Marcio Almada <marcio.web2@gmail.com=
> a
> > =C3=A9crit :
> >
> >> 2015-03-11 6:27 GMT-03:00 Lester Caine <lester@lsces.co.uk>:
> >>
> >> > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
> >>
> >> > Most of the examples being shown are examples of simple bad
> programming
> >> > practice that needs fixing anyway, and I would expect a proper code
> >> > review to have picked them up, so don't see that adding the check in
> PHP
> >> > is essential. It would however be a useful addition but in the
> E_STRICT
> >> > category ... not that I want to maintain that, but being able to
> ignore
> >> > those errors until such time as it is appropriate to fix them.
> >>
> >
> > I don't really see how this favors E_STRICT over E_NOTICE as any of thi=
s
> > type of errors can be displayed/hidden independently.
> >
> >
> >> I think this is a valid argument to keep the E_STRICT error level opti=
on
> >> for the secondary voting.
> >> That's a very useful information, thanks :)
> >>
> >
> > It also depends on your perception of E_STRICT. This level has been
> > introduced in 5.0 without being part of E_ALL in order to, among other
> > things, avoid too much pain in the *** while migrating from 4.x to 5.x.
> > As of 5.4, E_ALL contains E_STRICT and the difference between E_STRICT
> and
> > E_NOTICE/E_WARNING is certainly not in terms of severity.
> > Using an undefined variable or property =3D> notice.
> > Trying to get property of non-object =3D> notice.
> > Use of undefined constant =3D> notice
> >
> > For this reason, I think we should use the standard notice/warning/erro=
r
> > levels as much as possible. You may take a look at Nikita's "Reclassify
> > E_STRICT RFC" for more info about it.
> > https://wiki.php.net/rfc/reclassify_e_strict
> >
> > Cheers,
> > Patrick
> >
>
> I talked to Nikita earlier today, in order to try to align the strict arg
> count RFC with https://wiki.php.net/rfc/reclassify_e_strict and the
> conclusion was the following:
>
> It's a good thing to reclassify E_STRICT as this simplifies PHP error mod=
el
> and resolves the currently unclear role of strict standards notices. As a
> supporter of Nikita's idea, I'm removing E_STRICT from the voting options=
.
> Consider this my collaboration to help to unifiy the error level model an=
d
> go a bit farther from the current "error level buffet" state we got
> ourselves historically, on PHP.
>
> This leaves us with E_WARNING vs E_NOTICE and I'm sufficiently comfortabl=
e
> to allow a secondary voting between these two error levels.
>
> Thanks,
> M=C3=A1rcio
>

--047d7b86d8b26e4bdd05115b156b--