Function renaming. First attempt at defining some rules.

I've been discussing the business of function renaming etc with my colleague Tony, who has far more experience in designing elegant languages and instruction sets than I have. The following is a distillation of our combined thoughts. Firstly, I'm not sure that the way we are discussing things at the moment is quite getting to the root of the problem. Most posts are using a favourite group of functions, or the popular rule breakers as an illustration of how things should be changed. I think we need to get to the nitty gritty and write down what the rule should be. There seems to be general agreement that a function name should begin with the name of the extension which provides it (eg mysql). There also seems to be agreement that the extension name should be followed by an underscore. Several functions are deemed to be 'core' functions and should be allowed to have no prefix (possibly in addition to an alias which does have an extension prefix). All the functions do something, so without fail a verb is involved to tell us what the function does. In the simplest cases, no more is needed as extension_verb tells us enough (e.g. mysql_connect), but for more complex functions, the verb needs a noun to tell us which object the verb is doing its stuff to (e.g mysql_list_tables) (note that some extensions only act upon one type of object, so there may be a case for omitting the object when it is implicit?), and often it is some property of the noun we actually wish to affect (e.g. mcal_set_event_title - yes, I know this isn't how it currently is!). Finally (hopefully!) we sometimes wish to add an adverb to tell the verb how to behave - e.g. be case sensitive, raw, etc. In some existing cases, this adverb is rolled into the function name, but in others (and a better and more versatile solution, we think) the adverb is an optional final bitfield, boolean or integer argument to the function (as in sort(array array [,int sort_flags])). So, what this gives us is: extension_verb[object][property](...,[adverb]) Then we have to look at consistent use of verbs. One point which came to light was to standardise on set and get, rather than the rather erratic use of set, get, fetch, read, write. When it comes to whether or not to use underscores between the words in the function names, we suggest an underscore after the extension name and then none after that. That is the only way we can see of providing a scheme which allows us to still use standard C functions (like isalpha()) without breaking our own rules. When viewed in the light of the above (i.e. considering verbs, nouns etc), even the bits of php which we might have thought were fairly clean (eg mysql_...) are in need of a serious sorting out. Tony points out that the only way to convince anyone of the sanity of all this is to generate the list of functions as they should be, but since there are about 1600 functions in 84 extensions, if you managed one function every 20 seconds, then it would take you 9 hours to complete! And of course it would then be shot down in flames :) Let the shooting begin. -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org