Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115463
To: Abdul Haq Sheikh <khaweronline@gmail.com>, internals@lists.php.net
References: <CALOUi=BXYuQPzC-xBrwp0Srz4iDYmGQ8QnB3-K-7AmMe=uEveg@mail.gmail.com>
Message-ID: <1ce9c1d6-031e-42df-db4d-6b8c35cb148c@allenjb.me.uk>
Date: Sun, 18 Jul 2021 10:58:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <CALOUi=BXYuQPzC-xBrwp0Srz4iDYmGQ8QnB3-K-7AmMe=uEveg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] standardize php builtin functions
From: 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).