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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
