Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61531 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 40935 invoked from network); 20 Jul 2012 00:07:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Jul 2012 00:07:38 -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 67.192.241.203 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.203 smtp203.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.203] ([67.192.241.203:56142] helo=smtp203.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 33/11-18983-641A8005 for ; Thu, 19 Jul 2012 20:07:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp20.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 8D2572583D7; Thu, 19 Jul 2012 20:07:32 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp20.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 37D45258455; Thu, 19 Jul 2012 20:07:32 -0400 (EDT) Message-ID: <5008A143.7010203@sugarcrm.com> Date: Thu, 19 Jul 2012 17:07:31 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Gustavo Lopes CC: Nikita Popov , Sara Golemon , "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] zend_parse_parameters() improvements From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Default parameters and unpassed parameters enter the scene because it's > idiomatic to pass NULL to have the same effect as not passing that > parameter. Actually, as it never worked with int parameters, I'd not really call it idiomatic just yet. I was just thinking - since we have basically no code relying on this, why introduce rather artificial concept of "null means no parameter" (which I'm sure won't work in all cases and won't be expected in all cases) if we can have perfectly good concept "default means no parameter" which won't clash with any existing code? Note that this still will require something like l! - I'm actually working right now on finding all the places we have something like this for my default params patch - so I agree with that part of the argument. I'm just not sure adding that semantics to null is the best idea, since null can be a variable value and having something like mb_substr($foo, 0, $this->length) suddenly behave differently when $this->length is null would be somewhat unexpected effect. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227