Re: Resurrecting the Function Renaming Thread

It seems to me that the same arguments come over again and again. Let's summarize the concensus (well, hope it doesn't get to personal ;-): 1.0 - Objetives of a new Naming Scheme - Allow all PHP programmers to intuitively use new functions based on their previous PHP experience. - Allow all C, perl, python, whatever languages to find "standard" function names in PHP. - Make source code more readable. - Allow easier maintenance of the documentation. 2.0 - Contraints and Remarks - Standard functions borrowed from C and others MUST remain available for old-school coders to be at ease with PHP. - All functions that don't fit into the new naming scheme SHOULD be aliased and tagged for warnings. - Other functions, especially new ones SHOULD stick to the new naming scheme. - Compatibility with current names MUST be kept until a good period of time has allowed everyone to adopt the new naming scheme. - Warnings of Deprecated or To-be-deprecated function names MUST help the programmer to adopt the new standard whenever possible. - Compile options MAY be implemented to allow --with-names-strict --with-names-loose kind of implementations 3.0 - Renaming Schedule That applies to the next few releases of PHP. Phase 1 : aliasing old names to new names Phase 2 : send warning on to-be-deprecated functions ; remain silent on "standard" functions (strtok and co) Also send informative warnings pointing to the appropriate manual references. Phase 3 : force use of new naming scheme ; keep "standard" functions unchanged and provide their new naming scheme aliases 4.0 - Renaming Strategy notes - We have the PHP Coding Standard in CVS, we have PEAR and we have the PHP Functions List. Those three sources should be the best structures to pick from. PEAR especially SHOULD be the place where the new naming scheme is most implemented. - There is a difficulty for renaming extensions functions : should we stick to the extensions library function names or standardize our way ? PEAR does the unifying stuff (see DB::*) - Short names MAY be aliased for consistency (isset -> is_set) but the original MUST be kept. - Standard functions MAY be aliased for the novice, thus be quite informative (strtok -> str_tokenize) I think this is better than str_tok which doesn't mean anything more to the novice. On the other hand, making such functions long to type might help one look for shortcuts while being able to find a function by trial. - Too many FALIASes can be a bad option performance-wise. - Encoding the files (compiling the source ;-) may ease the process of renaming : either way, compiled files using this or that naming scheme should be the same in the end, shouldn't they ? That would please our friends at Zend... 5.0 - TODO.list Lots... I agree with Zak that we should start with the extensions. The database functions have been updated already for some of them. hellekin