Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84528
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error)
Date: Wed, 11 Mar 2015 10:05:03 +0100 (CET)
Reply-To: wp12173047-156224 wp12173047-156224 <dev@mabe.berlin>
To: marcio3w <marcio3w@gmail.com>, Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <1579682575.9673.1426064704052.JavaMail.open-xchange@app06.ox.hosteurope.de>
In-Reply-To: <54FFC96D.6090004@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Medium
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count
From: dev@mabe.berlin (wp12173047-156224 wp12173047-156224)

Hi Stas,

> Stanislav Malyshev <smalyshev@gmail.com> hat am 11. M=C3=A4rz 2015 um 05:=
49
> geschrieben:
>=20
>=20
> Hi!
>=20
> > related to the proposed RFC. *But* after some heuristics it was
> > noticeable that most warnings had a common cause. I parsed the output
>=20
> It doesn't matter if it has common cause or not. If I have a system of
> Wordpress-like size, I'm bound to get a lot of failures, that's what it
> is telling me. And 27 separate failures are non-negligible number.

This RFC doesn't add failures. It only makes failures visible. The failures=
 are
present without this this patch too but invisible.

> > some code refactory that left function calls with residual parameters
> > behind. This could be fixed in less than 1 hour.
>=20
> I think you are severely underestimating the cost of fixing it. Fixing
> bugs is not only replacing the bytes.

Same as above. The Bugs are there with and without this RFC.

> > The ZF2 test suite couldn't run because of fatal errors caused by PHP7
> > incompatibilities
> > or bugs that caused segfaults. Nothing related to the RFC itself.
>=20
> We do not know if something there is related to RFC or not. That's not
> evidence that RFC is OK, that's evidence that a) we could not obtain the
> information and b) we already have a BC problem so severe that we can
> not run ZF2, and probably not easily fixable (since, I assume, if it
> were easily fixable you'd have done so). That's why I am reluctant to
> add more BC breaks, especially ones that bring no new capabilities but
> just add more error messages. Each new BC break adds migration barriers,
> and in my opinion, it's not even linear.

The current fatals are not related to this patch. Sure, because of this it'=
s
unknown if there are other errors related to this patch but it doesn't make=
 this
RFC better or worse.

In my opinion this RFC only introduces a very very small BC break and only =
in
the case warnings are thrown as exceptions by the user (as in composer). Th=
is
RFC only makes currently invisible failures visible.

> > If compilation is "magic"... we are all magicians here. Calling the
> > implementation "magic"
> > won't change the fact that it's just a compilation check :D
>=20
> I didn't say compilation is "magic", you are strawmanning here. What I
> said is that having different behavior of the compiler depending on
> specific function calls made by the function being compiled is pretty
> rare (not only in PHP but in other languages too) and non-obvious, and
> thus suspicious.

First of all please be consistent with your meaning ... on discussion about
"$this from incompatible context" you liked to change a function callable o=
r not
if the function contains $this or not.=20

In the normal case also say the function body should not define anything ab=
out
how a function is callable but in this case the functions func_get_arg[s]
already do this.=20

> > BTW, the current PHP silent behavior should be considered even more
> > confusing otherwise we
> > wouldn't have these measurements:
> >=20
> > https://wiki.php.net/rfc/strict_argcount#bc_breaks_on_the_real_world
>=20
> I'm not sure how these prove current behavior is "confusing". Yes, there
> are bugs in the code, and I'm sure this feature will expose some of
> those (previously harmless) bugs. At cost of the BC break. And don't
> think a handful of libraries represent the vast universe of PHP code,
> most of which we can't even see because it's not published anywhere.

What do you mean here?

Again, introducing a warning isn't a real BC-break and as you says there ar=
e
bugs it helps nobody ignoring them. If you think so you can do that with al=
l of
your own bugs by ignoring warnings/notices.

> <snip>

Marc