Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68862
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.123 as permitted sender)
Message-ID: <5224F2EC.2090609@sugarcrm.com>
Date: Mon, 02 Sep 2013 13:19:56 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: PHP Internals <internals@lists.php.net>
References: <52243BA6.5040905@sugarcrm.com> <CAEZPtU5u+29CxpgDHs6GOoDUU+EWtm-8dr7NL4dufvSq+LZsyw@mail.gmail.com>
In-Reply-To: <CAEZPtU5u+29CxpgDHs6GOoDUU+EWtm-8dr7NL4dufvSq+LZsyw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Skipping parameters take 2
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> However I still wonder what prevents to finally implement named
> parameters too, it will provide the same feature while being even more

For named params, you need to rewrite all args handling, since now it is
a positional array and that doesn't work with named args. On the way
you'd have to refactor zend_parse_parameters to understand named args
(which aren't even named in many internals, so you'd have to add those)
and deal with functions that use + and * in various creative ways and
see how those can be reconciled with named params. And then of course is
the question of by-ref parameters and how to make the syntax handle
those too. Long story short, you'll have to rewrite everything that does
with argument passing, argument receiving or even peeks into arguments.

Skipping parameters is relatively simple - you just put NULL and fix
tons of functions which don't use defaults properly (will need to be
done on a larger scale with named params too, because named params means
you can skip args).

> handy and easier. I could dig the archives but I don't remember what
> was the reason why we rejected the idea back then.

Bikeshedding about the syntax mostly, but that all pales compared to
amount of work that needs to be done in the engine to support named
params. Unless, of course, I'm completely wrong and there's an easy way
to do it, which I am totally missing - in which case please point it out.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227