php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52424 Function naming inconsistency: htmlentities() x html_entity_decode()
Submitted: 2010-07-24 07:11 UTC Modified: 2010-07-29 02:09 UTC
Votes:59
Avg. Score:4.7 ± 0.9
Reproduced:52 of 54 (96.3%)
Same Version:34 (65.4%)
Same OS:27 (51.9%)
From: php-bugs at majkl578 dot cz Assigned:
Status: Wont fix Package: Unknown/Other Function
PHP Version: 5.3.3 OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2010-07-24 07:11 UTC] php-bugs at majkl578 dot cz
Description:
------------
I suggest adding a function htmlentities_decode() as a replacement for html_entity_decode() and possibly deprecate that one.
It is really misleading and unintuitive because there are functions htmlspecialchars() and htmlspecialchars_decode() doing similar thing.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-07-25 00:19 UTC] giorgio dot liscio at email dot it
php functions uses a lot of different syntax

isset
is_array
isPublic

but aliasing is evil and renaming is not appreciated by users... the best thing you can do is implement your renamed function in your namespace

bye
 [2010-07-29 02:05 UTC] 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.
 [2010-07-29 02:09 UTC] rasmus@php.net
-Status: Open +Status: Wont fix
 [2010-07-29 02:09 UTC] rasmus@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.
 [2013-01-23 17:06 UTC] 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.
 [2013-01-24 02:46 UTC] 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-24 04:03 UTC] 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 14:03 UTC] turneliusz at gmail dot com
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.
 [2013-01-24 15:54 UTC] chris at cgsmith dot net
It seems silly for any developer to change certain function names even though it 
is something in the back of there head.  It comes down to, "if it isn't broke, 
why 
fix it?".

But for a community this large and people that are trying out PHP and learning 
best practices, this needs to be done.

However, there needs to be a vote on the naming conventions that are used.  
Perhaps following PSR-1 or PSR-2.
 [2013-01-24 16:43 UTC] turneliusz at gmail dot com
I think we should keep current look and 
feel of this low level part of PHP, 
functions. I don't believe PSR have 
anything to do with that naming 
conventions. It could end up with some 
huge proposal about moving functions to 
some namespaces which would be huge 
change. I think it's just simple 
renaming we have to do. A real proposal 
about revolution in functions could be 
IMO autoboxing but this is another 
topic. And BTW that idea about providing 
switches in php.int could make huge 
mess. Let's deprecate and in major 
release remove, no incompatibility with 
same versions of PHP due to some magic
 [2013-01-25 13:23 UTC] martin dot keckeis1 at gmail dot com
+1 to make function name and parameters order more consistent!
 [2013-06-28 19:28 UTC] thatthatisisthatthatisnotisnot at gmail dot com
+1 for fixing naming conventions. It would be REALLY easy for most developers to 
refactor. The only exception being those who created their own functions with 
names that would be used by php core functions. That is if something was 
coreFunction() and the user created core_function(/*some custom function with 
almost the same name*/) and the new release changed to underscores.

It would be a burden on hosting companies to not break their users' software via 
an upgrade though. Someone with an old application and no one maintaining it 
could be in trouble if their host upgraded.
 [2013-08-01 20:05 UTC] duke at ejoom dot com
I agree for consistency. I've develop at PHP over 7 years and It's annoying that some time I should look up the proper function name or order (when editing without IDE).
By semver 2.0 we can do PHP ver. 6.0 with BC. So there projects can exist at 5.x. There is huge frameworks like Symphony and Zend Framework, Drupal and Joomla that was rewritten almost from scratch to utilize new features and architecture.
So GIVE people to choose which consistency to use CURRENT or NEW. After a one-two years It will appear needs for it or contraries.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 10:01:30 2024 UTC