Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68876 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22958 invoked from network); 2 Sep 2013 22:29:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2013 22:29:35 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.107 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.107 smtp107.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.107] ([108.166.43.107:41625] helo=smtp107.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 00/02-29856-E4115225 for ; Mon, 02 Sep 2013 18:29:35 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E999899017; Mon, 2 Sep 2013 18:29:31 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 5CB8F99003; Mon, 2 Sep 2013 18:29:30 -0400 (EDT) Message-ID: <52251149.4080308@sugarcrm.com> Date: Mon, 02 Sep 2013 15:29:29 -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: Nikita Popov CC: PHP Internals References: <52243BA6.5040905@sugarcrm.com> <5224F2EC.2090609@sugarcrm.com> <52250A97.8050406@sugarcrm.com> In-Reply-To: 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! > I think at some point you just need to go for "good enough" rather than > "optimal support for everything". If we don't support the rather special I am all for that. If only I wasn't this very minute bashed by several other people for not accounting for every exotic use case and not proposing optimal support for everything but just good enough for most practical use cases... > case of internal functions having variadic arguments followed by fixed > ones, I wouldn't consider that too tragic. It's not only this case, we have a number of internal functions that do weird things with their arguments. What "don't support" would mean in this case? > Also, what about internals - how the engine knows names of the > arguments there? > > > What do you mean by this? Internal functions. Some of them have arginfos which bear only passing resemblance with what these functions actually do. > I think the main use of named args is in specifying existing arguments > out of order. kwargs is a nice addition for minor use cases. I'll think > about how to support those a bit more. Option lists are everywhere, if you look at any framework everybody does it. Of course, now they do it with option arrays, and if we accept that option arrays are good then we don't need varargs either. But I thought the idea was that option arrays are not good enough actually. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227