On 03/04/2015 08:25 PM, Yasuo Ohgaki wrote: > Hi Rasmus, > > On Thu, Mar 5, 2015 at 1:46 AM, Rasmus Lerdorf <ras...@lerdorf.com > <mailto:ras...@lerdorf.com>> wrote: > > On 03/04/2015 08:26 AM, guilhermebla...@gmail.com > <mailto:guilhermebla...@gmail.com> wrote: > > @Rasmus: > > > > I don't see what's the problem of aliasing functions for the next 1-2 > > majors, deprecate the inconsistent one in the following and remove > later. > > As far as I am concerned str_len() would be the inconsistent one. Like I > explained previously, these function names for the most part, aren't > ones I made up. They come from the underlying libraries and whether you > personally value that or not, there is an actual reason for their names. > Many of them are iconic entities on their own, at least to people with > experience outside of PHP. Terms like "recvfrom", "getenv" and yes, > "strlen" are well-established names that should not be split up into > "recv_from", "get_env" and "str_len" due to some sort of arbitrary > consistency/purity idea any more than I should have my name changed to > Ras_mus. > > As many people have already suggested in this thread, if we are going to > do something here it has to bring actual value and can't just be a bunch > of aliases littering the global namespace further. > > > I have mixed feeling for well established names indeed. > These function names are debatable. Latest RFC leaves fopen()/fread()/etc > as it is now, for example. > > https://wiki.php.net/rfc/consistent_function_names#file_related_functions > > Personally, I don't mind to keep current names for strlen()/etc. > You don't mind at all to have php_version()/etc probably. It's possible to > have separate vote for names that are debatable or even keep current > names without vote. > > If you could provide list of debatable names, I'll have separate votes > for them > or keep current names without vote.
Every function name defined by IEEE Std 1003.1 along with the arguments and argument order would be on that list. When we have procedural functions that are either thin wrappers around or otherwise behave identically to an IEEE 1003.1 defined function, then the name and arguments currently match that specification quite well. Any deviation should have a really really good reason. You can find the full list here: http://pubs.opengroup.org/onlinepubs/9699919799/idx/is.html Click on the letters at the top for functions starting with the other letters. -Rasmus
signature.asc
Description: OpenPGP digital signature
