Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47775 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 18288 invoked from network); 4 Apr 2010 22:08:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Apr 2010 22:08:02 -0000 Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.117 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 63.205.162.117 us-mr1.zend.com Received: from [63.205.162.117] ([63.205.162.117:52775] helo=us-mr1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B6/1E-41826-0CD09BB4 for ; Sun, 04 Apr 2010 18:08:01 -0400 Received: from us-gw1.zend.com (us-ex1.zend.net [192.168.16.5]) by us-mr1.zend.com (Postfix) with ESMTP id E380743CD2; Sun, 4 Apr 2010 15:07:04 -0700 (PDT) Received: from [192.168.27.8] ([192.168.27.8]) by us-gw1.zend.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Apr 2010 15:07:58 -0700 Message-ID: <4BB90DB7.6060706@zend.com> Date: Sun, 04 Apr 2010 15:07:51 -0700 Organization: Zend Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hannes Magnusson CC: GM , internals@lists.php.net, Rasmus Lerdorf References: <745C5243-EB51-4D43-B036-8A34CDBBB547@gregory.net> <4BB68D61.2070301@lerdorf.com> <4BB6938F.7090404@zend.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2010 22:07:58.0161 (UTC) FILETIME=[48BB4410:01CAD443] Subject: Re: [PHP-DEV] Named Parameters From: stas@zend.com (Stanislav Malyshev) Hi! > The problem however is when an function accepts varargs (usually named > "...")..... if we however bring in strictct-ish naming convention I > don't see any immediate problems.... Varargs shouldn't be a problem and we don't even need ... there - we can just assume every function has implicit ... at the end (more or less what we are doing now). We have the following issues to overcome now: 1. We don't keep the name information on the receiving end. It should be pretty easy to fix - the parser knows the variable names. So instead of a number RECV opcode can just get a name, or maybe have separate name table that corresponds to numbers. 2. We don't have a way to pass the name information on the sending end - right now we use stack, which would not go well with named params. We'd probably have to switch to a hashtable - which would require substantial change to parameter change/receive code - but should be doable. Though introducing a hashtable may have performance impact there. 3. Combining named and un-named params can get weird - i.e. foo(1,2,3) is simple, foo(1, 2, bar => 3) is doable, but foo(1, 2, bar => 3, 4) would be trouble, since it is not clear at all where 4 should go to. Moreover, catching this situation can be non-trivial, as right now parsing nested function calls may not keep enough context for this. 4. varargs can be dealt with by either extending func_get_args() to provide name information or maybe by having some function that returns only those args that do not have matching names (that would make generic options easier to do). -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com