Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61533 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44279 invoked from network); 20 Jul 2012 00:29:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Jul 2012 00:29:14 -0000 Authentication-Results: pb1.pair.com header.from=glopes@nebm.ist.utl.pt; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=glopes@nebm.ist.utl.pt; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error) X-PHP-List-Original-Sender: glopes@nebm.ist.utl.pt X-Host-Fingerprint: 193.136.128.22 smtp2.ist.utl.pt Linux 2.6 Received: from [193.136.128.22] ([193.136.128.22:35677] helo=smtp2.ist.utl.pt) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C1/C1-18983-956A8005 for ; Thu, 19 Jul 2012 20:29:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 553F370003D7; Fri, 20 Jul 2012 01:29:10 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp2.ist.utl.pt ([127.0.0.1]) by localhost (smtp2.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id DBM2yBIZVB9s; Fri, 20 Jul 2012 01:29:10 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp2.ist.utl.pt (Postfix) with ESMTP id C351A7000439; Fri, 20 Jul 2012 01:29:09 +0100 (WEST) Received: from damnation (unknown [IPv6:2001:470:94a2:4:75ff:ee1e:5e2e:eb71]) (Authenticated sender: ist155741) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 1197E202250A; Fri, 20 Jul 2012 01:29:07 +0100 (WEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Stas Malyshev" Cc: "Nikita Popov" , "Sara Golemon" , "internals@lists.php.net" References: <5008A143.7010203@sugarcrm.com> Date: Fri, 20 Jul 2012 02:29:04 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?= =?utf-8?Q?ca_do_I=2ES=2ET=2E?= Message-ID: In-Reply-To: <5008A143.7010203@sugarcrm.com> User-Agent: Opera Mail/12.50 (Linux) Subject: Re: [PHP-DEV] zend_parse_parameters() improvements From: glopes@nebm.ist.utl.pt ("Gustavo Lopes") Em Fri, 20 Jul 2012 02:07:31 +0200, Stas Malyshev escreveu: >> 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. OK I should have qualified my statement -- it's idiomatic in userland. > > 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. I don't deny that 'default' would be clearer than 'null' (and certainly clearer than 3 commas in a row), but I wouldn't call this strategy innovative. A lot of userland code out there uses NULL in this fashion. I already had the opportunity to express my reservations about your proposal -- namely the effort required to purge ZEND_NUM_ARGS() usage vs the benefit, but since 1) you're apparently doing the work, 2) eases somewhat the way for named parameters, and 3) the default keyword was added, it doesn't seem so bad now. And just to clear, I agree with Sara that ! (both for l/d/b and the pointer types) should not be redefined to "parameter was passed". But it's my understanding that that's not what you're planning. -- Gustavo Lopes