Edit report at https://bugs.php.net/bug.php?id=52424&edit=1
ID: 52424
Comment by: martin dot keckeis1 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:
+1 to make function name and parameters order more consistent!
Previous Comments:
------------------------------------------------------------------------
[2013-01-24 16:43:46] 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-24 15:54:58] 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 14:03:43] 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 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.
------------------------------------------------------------------------
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
