Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21550 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5772 invoked by uid 1010); 15 Jan 2006 20:09:53 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 5757 invoked from network); 15 Jan 2006 20:09:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2006 20:09:53 -0000 X-Host-Fingerprint: 69.60.120.90 iconoclast.caedmon.net Linux 2.4/2.6 Received: from ([69.60.120.90:42023] helo=iconoclast.caedmon.net) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 7A/8C-13436-01CAAC34 for ; Sun, 15 Jan 2006 15:09:52 -0500 Received: from localhost ([127.0.0.1]) by iconoclast.caedmon.net with esmtp (Exim 3.35 #1 (Debian)) id 1EyEBx-000341-00; Sun, 15 Jan 2006 15:09:33 -0500 Message-ID: <43CAACD5.5050203@caedmon.net> Date: Sun, 15 Jan 2006 15:13:09 -0500 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Derick Rethans CC: Ron Korving , PHP Developers Mailing List References: <43C67431.9090003@prohost.org><3A366ACB-20D4-42C7-BBAE-46F643E3A91F@intuitivefuture.com><878581203.20060112153625@ionzoft.com> <7.0.0.16.2.20060112154219.029d06c8@zend.com><43C75FEE.7040908@php.net> <6C.F4.25674.EFD67C34@pb1.pair.com> <43C786E5.1020400@mysql.com> <43C7975A.2070504@php.net> <43C79801.7070101@mysql.com> <43C79A23.6010701@php.net> <43C79DC8.6000207@php.net> <43C79EE0.909@php.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Named arguments revisited From: sean@caedmon.net (Sean Coates) Derick Rethans wrote: > You do know that that means that we have to consistently name all > parameters to our 4000+ functions, right? On this note, and to throw in my 2c on the issue (from a doc standpoint): there are places in the manual where I've (personally) deliberately changed the parameter names that the developer chose, to make more sense in the docs. (I don't remember exactly where I did this, but I suspect it was in classkit or apc.) An example: (C): PHP_FUNCTION(some_file_function) { ... if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &strfn, &strfn_len) == FAILURE) ... (docs): mixed some_file_function( string $filename ) ... "fn" might make sense in C, but not in the docs (where it should be the more verbose "filename"). So, each function would need to not only standardize (as Derick mentioned)--having to lookup "fn" vs "filename" defeats the purpose of named parameters--but the docs would need to be synced for each function, too. While the thought of never remembering the parameter order again makes my mouth (mind?) water, I don't see how it could happen. As for userspace, a suitable framework could enforce this as associative arrays, with little overhead on the coding/execution fronts (especially juicy are the possibilities that have become available with Reflection). S