Edit report at https://bugs.php.net/bug.php?id=52424&edit=1
ID: 52424 Comment by: turneliusz at gmail dot com Reported by: php-bugs at majkl578 dot cz Summary: Function naming inconsistency: htmlentities() x html_entity_decode() Status: Wont fix Type: Bug Package: Unknown/Other Function PHP Version: 5.3.3 Block user comment: N Private report: N New Comment: Excuse me rasmus but WHY NOT? It's completely normal evolution process. Let's deprecated all things that have inconsistent naming in PHP 5.6 to be able to just remove them in PHP 6.0 where breaking compatibility would be possible. It would be just great to have PHP 6.0 as PHP 5.x with consistent function naming convention, with removed all of deprecated stuff. Previous Comments: ------------------------------------------------------------------------ [2013-01-24 04:03:23] nishant dot kanitkar at gmail dot com I don't see why this can't be done. Alias the functions to a single standard and depreciate the old ones. In the next version of PHP, add a configuration toggle ALLOW_LEGACY_FUNCTIONS set to default false. If ALLOW_LEGACY_FUNCTIONS is true, all the depreciated functions work as expected. If ALLOW_LEGACY_FUNCTIONS is false, all the depreciated functions throw errors. Keep the toggle in all future versions of PHP. Eventually applications using the legacy function names will either run a search-and-replace or fall out of use. It wouldn't be too difficult to migrate if the only change is a name change. ------------------------------------------------------------------------ [2013-01-24 02:46:34] php at lavoie dot sl The core functionsâ naming is one the most frowned upon "feature" of PHP and it is well overdue for a refactor. Old frameworks and application are a pain to convert, and it pretty pointless to do it for a cosmetic reason as rasmus pointed out, but I think the core devs are underestimating how much the community wants it done and how many people are willing to do their part. Letâs face it: â¢Â htmlentities/html_entity_decode ⢠str_replace/strtr â¢Â current/array_pop ⢠array_push($array, $item)/array_search($item, $array) I believe a very responsible roadmap would be to : 1. Create a PHP library that would essentially just wrap a function in another with consistent naming and arguments order. 2. Get some feedback of the community and work on the names. The guys at FIG would probably be a blessing on that. 3. Implement those using aliasing and a compiled extension. 4. Let it sit for a couple time while people get to know about it. 5. Merge extension into core. Real world application will begin to use it. 6. Drop the deprecated ones in a distant future. ------------------------------------------------------------------------ [2013-01-23 17:06:11] lenton64 at gmail dot com I feel that this is a big problem in PHP. It makes it super hard to remember function names (especially for newcomers) with these inconsistencies and gives PHP an ugly syntax reputation. Please change all function names to: words_separated_with_underscore() and then alias the original functions to the new ones. It may take a long time for everyone to change the functions in their applications but you can keep them aliased for however long everyone needs. This naming convention needs to become a standard in PHP at some point, why not get the ball rolling now. ------------------------------------------------------------------------ [2010-07-29 02:09:38] ras...@php.net We don't mind change, but our users really really don't like it when we break their working applications for cosmetic reasons. ------------------------------------------------------------------------ [2010-07-29 02:05:31] php-bugs at majkl578 dot cz Yes and that is what I think should change, because current naming conventions are really horrible. For instance, look at differences between str_replace, strlen, parse_str, htmlspecialchars. All work with same type but their names are completely different. So, string functions should go to String namespace (String\replace()), array functions to Array namespace (Array\search()) and so on. But unfortunately this will not happen because PHP does not like changes... Think about it. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=52424 -- Edit this bug report at https://bugs.php.net/bug.php?id=52424&edit=1