Hello Internals,
PHP has built in functions for string, array and math etc. But some string
and array functions start with Str_* and array_* but not all. If we
standardize php builtin functions so all string functions start with str_,
and all array functions start with array_ and all math functions start
with math_*, it will provide a lot of help to PHP developers. If we are
using VS Code, Sublime text, PHPStorm etc, developers will simply write
str_ or array_ or math_ and IntelliSensewill popup all string, array and
math functions. There will be no BC break, because math_floor() will be an
alias of floor()
and array_asort() will be an alias of asort()
,
file_basename will be an alias of basename()
.
- Prefix reaming string functions with str_*
- Prefix reaming array functions with array_*
- Prefix math functions with math_*
- Prefix file functions with file_*
Hello Internals,
PHP has built in functions for string, array and math etc. But some string
and array functions start with Str_* and array_* but not all. If we
standardize php builtin functions so all string functions start with str_,
and all array functions start with array_ and all math functions start
with math_*, it will provide a lot of help to PHP developers. If we are
using VS Code, Sublime text, PHPStorm etc, developers will simply write
str_ or array_ or math_ and IntelliSensewill popup all string, array and
math functions. There will be no BC break, because math_floor() will be an
alias offloor()
and array_asort() will be an alias ofasort()
,
file_basename will be an alias ofbasename()
.
- Prefix reaming string functions with str_*
- Prefix reaming array functions with array_*
- Prefix math functions with math_*
- Prefix file functions with file_*
Hi,
This has been proposed a number of times before. Please see:
A summary of the arguments around this change:
https://github.com/Danack/RfcCodex/blob/master/standardise_core_library.md
The Consistent Function Names RFC discussion (which was proposed for PHP
7): https://externals.io/message/84102
Personally I don't think the extension prefix on every function makes
sense. I think it would make more sense to utilize namespaces, or even
some future (built-in) concept of packages (this has been briefly
discussed a number of times, but as far as I know no one has actually
proposed anything concrete on this yet) to solve this problem. If it
ever happens, scalar objects would also resolve this. As the RFC Codex
notes, a lot of these names are not inconsistent with either other
languages and/or the libraries they originate from.
(Scalar objects is something that has been proposed, and even had
significant work done on an implementation -
https://github.com/nikic/scalar_objects - but I wouldn't hold your breath )
Even when looking for particular functionality, users should still refer
to the manual because they need to be aware of how to use functions
(correctly) and in some cases, even with a prefix, the function name to
do something won't be obvious for those unfamiliar with "programming
parlance", such as in the case of unlink.
There are also cases where I would suggest that simply adding a prefix
means you'll end up with a function name that doesn't actually make much
sense - consider, for example, 'file_file'. And some functions don't
necessarily belong to the extension you might expect them to be - for
example utf8_encode (yes, I know this is a bad function - it's just an
example) or md5. If there is going to be an effort to "fix" function
naming in some way, then I believe more thought should be put into it
that simply "add a prefix".
I think that having users rely on IDE auto-completion and even brief
documentation, and then "guessing" how to use functions based on names
is a bad idea. They might miss key details about how to use functions
correctly, or pointers to better ways to do things.
Having a large number of aliases in common use alongside the already
commonly used canonical function name is also, I believe, likely to be
confusing, especially to inexperienced developers - they're going to
wonder what the differences are between the aliases and the canonical
function (name)s and end up having to look at the manual even more.
If you specifically desire this in your project, it can be implemented
in a library. There are also a number of libraries on packagist that, at
least in part, attempt to tackle this in various ways (searching for
"consist" turns up some).