standardize php builtin functions

  115462
July 18, 2021 09:08 khaweronline@gmail.com (Abdul Haq Sheikh)
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_*
  115463
July 18, 2021 09:58 php.lists@allenjb.me.uk (AllenJB)
On 18/07/2021 10:08, Abdul Haq Sheikh wrote:
> 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_*
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).