Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83620
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.174 as permitted sender)
MIME-Version: 1.0
Reply-To: marcio3w@gmail.com
In-Reply-To: <54EB905C.6030706@mabe.berlin>
References: <54EB8043.7050108@mabe.berlin> <CAOsHV+uj4_aTLFeQL188v0VoX7DzKtWfAMYK9DtyM5ft27y8yA@mail.gmail.com>
 <54EB905C.6030706@mabe.berlin>
Date: Mon, 23 Feb 2015 20:03:21 -0300
Message-ID: <CAOsHV+s+ayByi3W0RjZBxiRY1AgHfKsVk-_a0o3bi=r8adHxjw@mail.gmail.com>
To: Marc Bennewitz <dev@mabe.berlin>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c38254d87978050fc9691a
Subject: Re: [PHP-DEV] Proposal: deprecate undefined passed arguments
From: marcio.web2@gmail.com (Marcio Almada)

--001a11c38254d87978050fc9691a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

2015-02-23 17:41 GMT-03:00 Marc Bennewitz <dev@mabe.berlin>:

>  Hi Marcio
>
> Wow, nice to see this - didn't noted it before.
>
> But I have to questions/notes:
> 1. Why you throw only a warning and not an error (deprecating this featur=
e
> first). I don't see the benefit.
>

Because
https://github.com/search?l=3Dphp&q=3Dfunc_get_args&type=3DCode&utf8=3D%E2%=
9C%93
brings 2,031,405 results. All packages made to support PHP 5.5 and below
will break. Remember PHP only got variadic functions on v5.6.

E_WARNING vs E_DEPRECATED is a debatable topic though. E_DEPRECATED means
func_get_args() will be removed some day, while E_WARNING means
func_get_args() will not be removed and will stay as an option to explicit
variadic fucntions. That's a legit topic to throw on discussion phase IMMO
(though we probably already know the result...)

2. As I understand it correctly passing unknown arguments will be allowed
> if the function uses one of the func_[get|num]_arg[s]() functions.
>
> This looks wired to me as the caller should not know the body to know how
> a function can be called
> and because of the dynamic nature of PHP this check isn't possible in all
> cases as you already noted.
>

Yes, hence why I'm proposing to block dynamic calls to *func_get_args()
func_num_arg()* API, see
https://wiki.php.net/rfc/strict_argcount#open_issues


>
> Additionally such strict check is for detecting wrong calls but this
> detection doesn't work with code like this:
> https://github.com/zendframework/zf2/blob/master/library/Zend/Cache/Stora=
ge/Adapter/Memcached.php#L213
>

That's a great point! Maybe *func_num_args()* detection shouldn't mark the
function as sensitive to dynamic argcount. I only added it for
"completeness", but now I see that maybe it was an unnecessary
implementation detail.


>
> In my opinion functions using func_[get|num]_arg[s]() to implement
> variadic arguments are totally outdated and should be refactored using ne=
w
> semantic. I also think such code isn't used very often and deprecating it=
 +
> removing later on (PHP 8) will give more than enough time to update it as
> it's simple to find and simple to fix.
>
> Also to previous example given for ZF2 shows that the function
> func_num_args() have it's rights to exit but i'm unsure about
> func_get_arg[s]().
>
> Marc
>

I agree with you here, but honestly, deprecating *func_get_args()* is not a
passable option because people currently still have to support PHP 5.5 and
it has no variadic functions. I had this same idea, originally, but then
reality bitten and I decided to do the compile time check for the
variable-lengh argument list API usage.

M=C3=A1rcio Almada.

--001a11c38254d87978050fc9691a--