Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83603
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <54EB8043.7050108@mabe.berlin>
References: <54EB8043.7050108@mabe.berlin>
Date: Mon, 23 Feb 2015 17:15:09 -0300
Message-ID: <CAOsHV+uj4_aTLFeQL188v0VoX7DzKtWfAMYK9DtyM5ft27y8yA@mail.gmail.com>
To: Marc Bennewitz <dev@mabe.berlin>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134573c4615b0050fc710d7
Subject: Re: [PHP-DEV] Proposal: deprecate undefined passed arguments
From: marcio.web2@gmail.com (Marcio Almada)

--001a1134573c4615b0050fc710d7
Content-Type: text/plain; charset=UTF-8

2015-02-23 16:32 GMT-03:00 Marc Bennewitz <dev@mabe.berlin>:

> Hi all,
>
> Because the feature freeze for PHP 7 is near I like to know your thoughts
> about one more change in passing arguments. Sure this one would introduce
> one more deprecated message / BC break but this one s for reducing BC break
> in the future!
>
> Currently a caller can pass undefined arguments as much he like. Such
> passed arguments are only visible by the callee using
> func_get_args/func_num_args but the need for such function definitions has
> been gone with argument unpacking feature. The other rare possibility for
> ignoring passed arguments by callables from functions like array_walk has
> been gone, too, with the introduction of clusures.
>
> By the way we already have internal functions triggering warnings on
> unknown arguments. This is also an unneeded inconsistency and more it's
> invisible by the user without testing each function for it.
>
> At least simply ignoring passed arguments is a violation as described in
> the following examples (http://3v4l.org/U2lnf):
>
> class Calculator {
>     public function calc($v) {
>         return $v + 1;
>     }
> }
>
> class MyCalculator extends Calculator {
>     public function calc($v1, $v2 = 0) {
>         return parent::calc($v1) + $v2;
>     }
> }
>
> function calcArray(array $values, Calculator $calculator) {
>     foreach ($values as &$v) {
>         $v = $calculator->calc($v, $v); // Second argument is wrong !!
>     }
>     return $values;
> }
>
> $ar = [1,2,3];
> var_dump(calcArray($ar, new Calculator));   // ignores the second argument
> var_dump(calcArray($ar, new MyCalculator)); // UNEXPECTED:  the second
> argument will be used
>
>
> Both calculators should be 100% compatible but they aren't as the function
> "calcArray" shows.
>
>
> So because of the described issues with the existing code base I like to
> propose the change to no longer ignore undefined arguments and introduce
> E_DEPRECATED messages if a function get's an undefined argument. So the
> user get enough time to fix their code before throwing errors in this case
> in PHP 8.
>
> As this should be consistent over the engine I would propose this change
> for user defined functions and for internal functions as well.
>
> Again, yes this one would introduces one more BC break but first this
> would be deprecated before disabled and next it's for reducing BC in the
> future.
>
> Marc
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Have you checked https://wiki.php.net/rfc/strict_argcount? Only difference
is that I'm proposing a warning instead of E_DEPRECATE, but it's still a
draft and open to discussion. Maybe you would like to contribute to the RFC
before it reaches discussion this week?

--001a1134573c4615b0050fc710d7--