Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84316 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70777 invoked from network); 5 Mar 2015 05:14:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Mar 2015 05:14:14 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.220.44 as permitted sender) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.220.44 mail-pa0-f44.google.com Received: from [209.85.220.44] ([209.85.220.44:38145] helo=mail-pa0-f44.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F2/C0-56703-026E7F45 for ; Thu, 05 Mar 2015 00:14:11 -0500 Received: by pabrd3 with SMTP id rd3so15630669pab.5 for ; Wed, 04 Mar 2015 21:14:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=5lHy5VIRPJY0hzHZpLOhLLXChtycZjDCBCc81yNZY1U=; b=AL8rMcDzEKDJ7zrT0+vwzyKZFwVKOMmLCwOib0UD0yb6D9MtFS9ZM2RIsn15yiQb++ 0SFx/0yMZL9+u6z9S9IeyAOx97aNLu1eoy1bmetcRK/jbPfKFMF1UhfMEjrrn18TTWl3 KUBvXo3m7+tvTjMNxbjrATNIecmKsxKfdNIIBUQ8MewGFNxSUZPqawt/tYcgDoRw2LpC q/d2XlRMPml7/nW28t4mlzXZgjaAAs6uxqM/heXR+rGp6qRsxYxHYI6wwI85KbQaN7GD K9tvBTrQsozEl6EPYBGCGlr8M3mlKvQ+d5kcLW7A1gB9LRGTP75QXHH4HnVKiFq5YooH PnVQ== X-Gm-Message-State: ALoCoQn3ux8y2Li8FOPPQTw3Ts+uN5F1Q71CnXIQRgQHesdzacxxWiebNb6TPHqgx5pkXfhlO+dt X-Received: by 10.68.57.168 with SMTP id j8mr12521317pbq.135.1425532446338; Wed, 04 Mar 2015 21:14:06 -0800 (PST) Received: from [192.168.200.14] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPSA id ey10sm1220257pab.47.2015.03.04.21.14.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 21:14:04 -0800 (PST) Message-ID: <54F7E61B.4040301@lerdorf.com> Date: Wed, 04 Mar 2015 21:14:03 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yasuo Ohgaki CC: "internals@lists.php.net" References: <54F4F3FC.6060501@fischer.name> <54F4FDFB.8010701@lsces.co.uk> <54F5895D.3090002@gmail.com> <554F0C3F-770F-4694-A5AB-FDC54FCCBF00@gmail.com> <54F72360.6000702@lerdorf.com> <54F73702.9050806@lerdorf.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VPUNc8PdgoD2B6BNp5t6v8qeQxFMNcjj8" Subject: Re: [PHP-DEV] Consistent function names From: rasmus@lerdorf.com (Rasmus Lerdorf) --VPUNc8PdgoD2B6BNp5t6v8qeQxFMNcjj8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/04/2015 08:25 PM, Yasuo Ohgaki wrote: > Hi Rasmus, >=20 > On Thu, Mar 5, 2015 at 1:46 AM, Rasmus Lerdorf > wrote: >=20 > On 03/04/2015 08:26 AM, guilhermeblanco@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 remov= e later. >=20 > As far as I am concerned str_len() would be the inconsistent one. L= ike 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 n= ames. > Many of them are iconic entities on their own, at least to people w= ith > experience outside of PHP. Terms like "recvfrom", "getenv" and yes,= > "strlen" are well-established names that should not be split up int= o > "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. >=20 > As many people have already suggested in this thread, if we are goi= ng to > do something here it has to bring actual value and can't just be a = bunch > of aliases littering the global namespace further. >=20 >=20 > I have mixed feeling for well established names indeed. > These function names are debatable. Latest RFC leaves fopen()/fread()/e= tc > as it is now, for example. >=20 > https://wiki.php.net/rfc/consistent_function_names#file_related_functio= ns >=20 > Personally, I don't mind to keep current names for strlen()/etc.=20 > You don't mind at all to have php_version()/etc probably. It's possible= to=20 > have separate vote for names that are debatable or even keep current > names without vote. >=20 > 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 --VPUNc8PdgoD2B6BNp5t6v8qeQxFMNcjj8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlT35hsACgkQlxayKTuqOuClZACgiE3gyk1ea4v3N7cHKp52ws/M pycAniSReMy5BaO8h5xRCuJEpZm2RhAU =dqSV -----END PGP SIGNATURE----- --VPUNc8PdgoD2B6BNp5t6v8qeQxFMNcjj8--