Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84522
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.182 as permitted sender)
Message-ID: <54FF8CED.5030701@gmail.com>
Date: Tue, 10 Mar 2015 17:31:41 -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, PHP internals <internals@lists.php.net>
References: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@mail.gmail.com>
In-Reply-To: <CAOsHV+uApxF=pQngonMppam2AEnW0Sm1ESAaB9exLH0K0hMBWA@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!

>    - Even if you already read the RFC in the past, read it again now.
>    - Don't claim **possible** massive BC breaks before read the
>    measurements already done. No matter how seasoned you are with PHP, real
>    numbers matter most than assumptions. Your measurements are welcome too.

I'd say your own data - 4597 warnings on 27 different cases of calls -
is quite fitting the "massive BC break" category. If I had some app and
had to evaluate the upgrade to PHP 7 and would see that it produces
thousands of errors and I have to patch dozens of separate places to fix
it (your data doesn't say if the sources of the calls are the same, so I
take the best interpretation - that both source and target are the same)
- I would postpone the upgrade as far as possible, because it looks like
a huge disruption.

Additionally, ZF2 tests couldn't even run - and from this you conclude
that your patch is fine. I conclude that we already have a big problem,
and making it worse is not a good idea. If we do it couple of more
times, we'd probably get people to run PHP 7 somewhere in 2025.

Additionally, I feel bad about magic features that change depending on
which code is inside the function. That doesn't feel like a good design.

Additionally, there is more than variadic functions which may use extra
parameters. Such as dynamic dispatch:

function getVariables($vars, $arg) {
  foreach($vars as $var) {
     $getter = "get$var";
     $result[] = $this->$getter($arg);
  }
  return $result;
}

grossly simplified of course. Now imagine some getters need the arg and
some don't. I can't write this code anymore without either:
1. Adding argument to all getters even though they don't need it
(unclean and confusing)
2. Checking how many arguments each getter needs and modifying the loop
accordingly (even more confusing)

>    - Try the patch. Really.
>    - Consider reading the use case present on this post: goo.gl/3ykdIy

The case you bring there looks artificially constructed to support this
RFC. If your unit tests are so bad as to not actually check that the
functions like createUser() do actually create the user you asked to
create and don't just drop information on the floor, and your code
refactoring practices are so bad as to allow people just drop arguments
from public APIs and replace them with other arguments, and all this
without checks or typing - parameter counts is not what is going to save
you. Your own example would break if both changes are done at the same
time (if you can do either of them, no reason why you can't do both).

-- 
Stas Malyshev
smalyshev@gmail.com