Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84524
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.171 as permitted sender)
Message-ID: <54FFC96D.6090004@gmail.com>
Date: Tue, 10 Mar 2015 21:49:49 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: marcio3w@gmail.com
CC: PHP internals <internals@lists.php.net>
References: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com> <54FF8CED.5030701@gmail.com> <CAOsHV+sdkSnrB_ZSHE1T81rnBt1K58-_fOzt6-kjHpghmjV5kA@mail.gmail.com>
In-Reply-To: <CAOsHV+sdkSnrB_ZSHE1T81rnBt1K58-_fOzt6-kjHpghmjV5kA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> related to the proposed RFC. *But* after some heuristics it was
> noticeable that most warnings had a common cause. I parsed the output

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.

> some code refactory that left function calls with residual parameters
> behind. This could be fixed in less than 1 hour.

I think you are severely underestimating the cost of fixing it. Fixing
bugs is not only replacing the bytes.

> 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.

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.

> 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

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.

> If you plan to use methods|functions interchangeably then you should
> make them compatible
> from now on. That's one of the points of the RFC. It's not "unclean".

You basically just choose to ignore my argument here, recognizing that I
correctly identified the case where BC break would happen but saying you
don't care about it. Other people that do use such code may care.
And yes, I consider adding unnecessary parameters to a function just to
satisfy some warning "unclean".

> BTW, the current PHP silent behavior should be considered even more
> confusing otherwise we
> wouldn't have these measurements:
> 
> https://wiki.php.net/rfc/strict_argcount#bc_breaks_on_the_real_world

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.

> It basically means that even experienced package maintainers are
> shooting on their own foot and
> they are using code evaluation tools, static analyzers, etc. Now imagine
> the common PHP programmer.

Yes, experienced programmers make bugs. Inexperienced programmers make
bugs too. Nobody ever claimed otherwise. The point is not about that,
the point is in this case the cure may be worse than the disease.

> You can't claim that I artificially built the test suites of a lot of
> open source
> projects just to "support the RFC". The test suites (and the code being

Coincidentally, I also didn't claim that. Should we go and enumerate
more things that I can't claim and actually didn't, or we are ready to
proceed to discussing things I actually did claim?

> - and there it is: the same patterns from the "artificial" example were
> detected
> numerous times "on the wild".

No, your example talks about something completely different - removing a
parameter used by the code and the tests completely missing that even
though the API requires that parameter to be used, and then adding
another parameter in place of that previous parameter and giving it
completely different meaning and the tests missing it again. If some
framework in the wild has such code changes and such tests, they need to
seriously upgrade their testing game.

-- 
Stas Malyshev
smalyshev@gmail.com