Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83639
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.45 as permitted sender)
Message-ID: <54EC2BC1.9030204@gmail.com>
Date: Mon, 23 Feb 2015 23:44:01 -0800
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: Marc Bennewitz <dev@mabe.berlin>, 
 PHP internals <internals@lists.php.net>
References: <54EB8043.7050108@mabe.berlin>
In-Reply-To: <54EB8043.7050108@mabe.berlin>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Proposal: deprecate undefined passed arguments
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 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.

I don't think it is a good idea to break all functions that use
func_get_args(). To have a BC break, there should be a larger
improvement in the functionality, compensating for it, but here no
functionality is added, just removed, and removed for apparently no
reason besides trying to be "more strict". I know that's some kind of
fashion lately to introduce limitations in the language that add nothing
but "strictness" but frankly I see no point in this one. If there is
some perceivable improvement in easiness of development, or some added
capabilities which are enabled by this, or some problem that was hard to
solve before but with this change is easy - please describe it, so far I
didn't see it.

> As this should be consistent over the engine I would propose this change
> for user defined functions and for internal functions as well.

If you are worried about consistency that much, I would propose removing
warning from internal functions, since it is not very useful for any
real purpose anyway - extra argument does not hurt anything, just
produces annoying messages.

> 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.

Deprecating is not a magic trick that makes BC breaks OK. Deprecating is
a way to handle BC breaks, but it doesn't make it any better so it can
not be used as an argument for BC break being more acceptable. *If* BC
break is warranted then we can talk about how to do it, i.e. with
deprecation, etc. but for that we need to first decide that the break is
OK, without relying on specific process for achieving it as an argument.

Also, I don't exactly see how it reduces BC breaks in the future. BC
promise does not include a promise not to add function arguments.
-- 
Stas Malyshev
smalyshev@gmail.com