Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47771 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93776 invoked from network); 3 Apr 2010 23:59:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Apr 2010 23:59:32 -0000 Authentication-Results: pb1.pair.com smtp.mail=brian@moonspot.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=brian@moonspot.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain moonspot.net designates 72.5.90.27 as permitted sender) X-PHP-List-Original-Sender: brian@moonspot.net X-Host-Fingerprint: 72.5.90.27 smtp.dealnews.com Linux 2.5 (sometimes 2.4) (4) Received: from [72.5.90.27] ([72.5.90.27:55382] helo=smtp.dealnews.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3D/1C-41826-466D7BB4 for ; Sat, 03 Apr 2010 18:59:32 -0500 Received: (qmail 29516 invoked from network); 3 Apr 2010 23:59:21 -0000 Received: from unknown (HELO mail.dealnews.com) (10.1.10.7) by -H with ESMTPS (DHE-RSA-AES256-SHA encrypted); 3 Apr 2010 23:59:21 -0000 Received: (qmail 31022 invoked from network); 3 Apr 2010 23:59:29 -0000 Received: from h105.248.18.98.static.ip.windstream.net (HELO Brian-Moons-MacBook-Pro.local) (brianm@98.18.248.105) by -H with ESMTPA; 3 Apr 2010 23:59:29 -0000 Message-ID: <4BB7D661.4090909@moonspot.net> Date: Sat, 03 Apr 2010 18:59:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Stanislav Malyshev CC: Rasmus Lerdorf , GM , internals@lists.php.net References: <745C5243-EB51-4D43-B036-8A34CDBBB547@gregory.net> <4BB68D61.2070301@lerdorf.com> <4BB6938F.7090404@zend.com> In-Reply-To: <4BB6938F.7090404@zend.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Named Parameters From: brian@moonspot.net (Brian Moon) >> I really doubt named parameters would have much of an impact on >> anything, but I'd be willing to consider it if a clean implementation >> was to show up. > > I think they'd allow to manage complex parameter sets more efficiently > than with those $options arrays. But that'd probably require changing > the way how parameters are passed, since the stack won't work too good > anymore for it. Is the desire for named parameters to only have it for user land function/methods? If so, I am kind of -.5 on this because that would be a little WTF for a new user. If not, then it is a huge undertaking as every internal function and pecl extension would have to be updated to support them. In which case it is a ton of work. I have long ago started passing arrays and doing validation myself, which sucks. I admit, named parameters + scalar type hints would be quite nice and simplify a lot of my code. Brian.