Hi Rasmus, On Thu, Mar 5, 2015 at 1:46 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> On 03/04/2015 08:26 AM, 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. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
