Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60197
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
In-Reply-To: <4F8DF4B1.2040307@sugarcrm.com>
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
References: <4F8DF4B1.2040307@sugarcrm.com>
To: "PHP Internals" <internals@lists.php.net>, "Stas Malyshev"
 <smalyshev@sugarcrm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
Date: Wed, 18 Apr 2012 22:15:16 +0200
Message-ID: <op.wcy87qrzidpuyk@damnation.mshome.net>
User-Agent: Opera Mail/11.62 (Win32)
Subject: Re: [PHP-DEV] [RFC] skipping optional parameters
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Wed, 18 Apr 2012 00:54:41 +0200, Stas Malyshev <smalyshev@sugarcrm.co=
m>
wrote:

> [snip]
> https://wiki.php.net/rfc/skipparams
>
> [snip]

=C2=ABFor internal functions, parameter parser will ignore the NULLs, th=
us
leaving the defaults supplied by the caller intact. Again, skipping
non-optional parameter is an error.=C2=BB

This would cause a lot of problems. Basically, all the functions that re=
ly
on ZEND_NUM_ARGS() will have to be changed. You can't tell if a paramete=
r
was passed or not by relying on it.

For instance, if you have ZEND_NUM_ARGS() yielding x, but skipped arg x =
-
y, now the variable for the argument x - y won't be touched but the
function will think the argument was supplied. Segfaults and unpredictab=
le
behavior due to uninitialized values and other logic errors will follow.=


Of course, this because internal functions don't have "default values", =
at
least not the same way user-land functions do.

This seems a lot of trouble for a feature that, in my opinion, even if i=
t
could be implemented without problems, won't be useful enough to overcom=
e
the strong presumption that exists against new syntax changes. Maybe I'm=

lucky, but the problem you're trying to solve is at most an occasional
minor nuisance for me. Plus, this solution encourages bad behavior. If w=
e
want to properly support long argument lists (and I'm not we do), we hav=
e
to have named parameters.

-- =

Gustavo Lopes