Re: Function renaming. First attempt at defining some rules.

From: 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

« previous php.qa (#2399) next »