Re: Function renaming. First attempt at defining some rules.
| From: | Phil Driscoll | Date: | Wed, 14 Feb 2001 16:05:59 +0000 |
| Subject: | Re: Function renaming. First attempt at defining some rules. | ||
| Groups: | php.qa | ||
| Request: | Send a blank email to php-qa+get-2399@lists.php.net to get a copy of this message | ||
Cynic wrote:
>IMO requiring a verb in all function names is too much. While rigid purity
>might be a goal, I'm not after it. The world isn't black and white.
Requiring
>e. g. "get" might be feasible if the function has a "set" counterpart. But
><db extension>_error is a good function name IMO. I prefer it over
><dbext>_error or <dbext>_get_error or <dbext>_get_error_message or
><dbext>_geterrormessage.
Indeed there may well be several places where it might be sensible to miss
out the verb (or to provide an alias which misses out the verb), and
get_blah where there is no set_blah is one of them.
>So you mean you're in favor of nuking all those arsort's, krsort's and
alike
>and replace them with flags to [array_]sort? I don't like that idea.
I'm not in favour of nuking anything at all - I want current stuff to
continue to work, but where functionality is all but identical then I would
prefer the adverb to go in as a parameter, but could live with the less
versatile 'adverb as the last word in the function name'.
>I don't believe this will be seriously evaluated. THE unanimous agreement
>has been NoStudlyCaps, and I believe that means Seriously_NoStudlyCaps.
>-1 all the way to the Supreme Court.
I can vouch for the fact that is wasn't quite unanimous :) - but here I am
expressly NOT wanting studly caps. Lower case only is the thing which will
give us compatibility with the standard C functions namespace.
Cheers
dives behind a rock to take cover again :)
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org