Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84209 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30405 invoked from network); 3 Mar 2015 00:03:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Mar 2015 00:03:26 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.220.42 as permitted sender) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.220.42 mail-pa0-f42.google.com Received: from [209.85.220.42] ([209.85.220.42:40937] helo=mail-pa0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 87/95-14834-D4AF4F45 for ; Mon, 02 Mar 2015 19:03:26 -0500 Received: by padfb1 with SMTP id fb1so9406203pad.7 for ; Mon, 02 Mar 2015 16:03:22 -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=hdspAw21mIWlProOYum4kW2u+UzNYIyt7CTWk9C0LNk=; b=FQJeADJYyh9IqcAhkug2tUMZ4glG9y9juUV602GGyq6F8ktpJ0a8/69n4U0LGoWfhb a70Fa/8OBkYYX2dmcsC7rcGEGBEcHEWqfG4H62YCf1nSU9UMvC+cUJO0rA3u5qGmJ7mn hoqiSZSxTTzNaQ7qGOWtmhhXTfO9lFSx7ZZBM71anFxAuDqtd2t4pMvjUdXkDPq9Q1WM UjoYYRhy5eELPwf7B5GyiFJN7pNBqjIOlq9iBadEAA6Q/N3eDu5exP3aLNVnkVYxwyez Ywbvv7eACGASYnjTCK9VJd/cRtrERlxVwqYegfbJPopD/oJY3B1ANIgEj2/Te0EE5uG/ ktMw== X-Gm-Message-State: ALoCoQlAG3/uZ2GATqiWwCj22XlZGfh4rTy0nMqFSMr+nqJ9OCIR5mTIAJtOORFX7DJt1/Yi3wSs X-Received: by 10.70.28.130 with SMTP id b2mr51626895pdh.48.1425341001610; Mon, 02 Mar 2015 16:03:21 -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 ib3sm10980427pbb.15.2015.03.02.16.03.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2015 16:03:20 -0800 (PST) Message-ID: <54F4FA47.2020108@lerdorf.com> Date: Mon, 02 Mar 2015 16:03:19 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Yasuo Ohgaki , Markus Fischer CC: "internals@lists.php.net" References: <54F4E29D.7080501@garfieldtech.com> <54F4E93C.80206@gmail.com> <54F4EBEC.2090702@garfieldtech.com> <54F4F3FC.6060501@fischer.name> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Omn3CKb1avVgRlQ30QnLePiq2ejmj8hi" Subject: Re: [PHP-DEV] Consistent function names From: rasmus@lerdorf.com (Rasmus Lerdorf) --4Omn3CKb1avVgRlQ30QnLePiq2ejmj8hi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/02/2015 03:54 PM, Yasuo Ohgaki wrote: > Hi Markus, Larry and Rowan, >=20 > On Tue, Mar 3, 2015 at 8:36 AM, Markus Fischer wr= ote: >=20 >> On 03.03.15 00:10, Yasuo Ohgaki wrote: >>> I would love to have new & clean APIs. >>> >>> Please think my proposal as legacy API cleanups. Many of candidates w= ill >>> remain >>> without CORDING_STANDARSDS confirmed names almost forever. This is wh= at >>> I would like to improve. If you don't care about legacy stuff cleanup= s, >>> please don't >>> care. The cleanups will not hurt anything, almost. >> >> No ill intentions here, but adding the aliases and, as you propose, >> literally adding *hundreds* of aliases is actually a mess to me. >> >> What you call "new & clean" is as a shield for effectively introducing= >> duplicates. You do not clean up anything that way. You leave a even >> bigger mess behind. By going for your honorable goal of correcting >> things I think you got lost in the woods. >> >> IMHO the only forward is to make sure new/future additions to the >> language adhere to the coding standard or use a smart way (i.e. the >> scalar addition). >=20 >=20 > I think I understand your point very well. > However, I have an urge impulse to add standard confirmed names > when I see manual pages like >=20 > http://php.net/manual/en/book.gettext.php > bind_textdomain_codeset =E2=80=94 Specify the character encoding in whi= ch the > messages from the DOMAIN message catalog will be returned > bindtextdomain =E2=80=94 Sets the path for a domain > dcgettext =E2=80=94 Overrides the domain for a single lookup > dcngettext =E2=80=94 Plural version of dcgettext > dgettext =E2=80=94 Override the current domain > dngettext =E2=80=94 Plural version of dgettext > gettext =E2=80=94 Lookup a message in the current domain > ngettext =E2=80=94 Plural version of gettext > textdomain =E2=80=94 Sets the default domain >=20 > This looks awful... just cannot put up with... These come from the underlying libaries. You can type "man dcgettext" or "man bind_textdomain_codeset" at your Linux command line and learn a lot about how these work. Plus, if you are a C dev, much like strlen(), these are simply the names you expect, or at least they are instantly recognizable to you. As I normally explain to people, there is vertical consistency here, not horizontal consistency. I understand how people who don't have a background in the underlying libraries might wish for a different API and horizontal consistency across disparate extensions, but simply adding a bunch of aliases that have no basis in anything doesn't help anybody. -Rasmus --4Omn3CKb1avVgRlQ30QnLePiq2ejmj8hi 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 iEYEARECAAYFAlT0+kcACgkQlxayKTuqOuBl5wCfWf96coCDO7r8HARfM4FjrTEW d/sAn3owzkNcn4NZiiR3FZ45GKnFoLiH =cmFf -----END PGP SIGNATURE----- --4Omn3CKb1avVgRlQ30QnLePiq2ejmj8hi--