Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70950
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.128.52 cause and error)
Message-ID: <52C4ADC8.1090009@lerdorf.com>
Date: Wed, 01 Jan 2014 16:07:36 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
References: <CAGa2bXZJoyV+9qN6v8j3+vHexoqDtHR4cZkgdtdc1GpVkDaD9w@mail.gmail.com> <CADNQb0WnEM8hE3=ns3fFaaqNdcBTAJUytvLY-G1C5pvB4tTgmA@mail.gmail.com> <52BE8F35.9090104@b1-systems.de> <52C4A415.3040101@gmail.com>
In-Reply-To: <52C4A415.3040101@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="BufdcToq2MHfqsTKBVuxLjNKAQ29KwT24"
Subject: Re: [PHP-DEV] [PHP6] Function name consistency
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--BufdcToq2MHfqsTKBVuxLjNKAQ29KwT24
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 1/1/14, 3:26 PM, Rowan Collins wrote:
> On 28/12/2013 08:43, Ralf Lang wrote:
>> When redesigning for PHP6, shouldn't most functions move to a class or=

>> namespace in the first place?=20
>=20
> You make it sound like such a redesign is an obvious and achievable goa=
l
> for the next "major" release of PHP. Neither PHP 5 nor the abandoned PH=
P
> 6 branch (Unicode strings, plus the features which were released as 5.3=

> and 5.4 instead) attempted anything so radical, and the more you change=
,
> the harder it is to persuade people to migrate.
>=20
> I suspect this has been discussed a lot of times, although I've only
> joined the list recently. A search through the archives before taking
> this discussion further would probably avoid repeating arguments that
> have been had before, unless anyone has a good summary somewhere?
>=20
> Not that I'm against moving towards consistency per se, but I wouldn't
> want to assume that whatever stopped it gaining traction in the past no=

> longer applies.

You also need to realize that there is consistency. It is just
consistency from a different angle. PHP from day one was always a very
thin wrapper on top of dozens, now hundreds, of underlying libraries.
The function names and argument order, for the most part, were taken
directly from these underlying libraries. So if you were familiar with
MySQL's C API, for example, you would instantly be able to navigate
PHP's mysql functions to the point where we barely needed PHP MySQL
documentation because MySQL's C library documentation covered it
function for function. And for many of the str functions (the ones
without an underscore), try typing: man
strlen/strchr/strrchr/strtok/strpbr/strspn... at your Linux command line
prompt.

This approach covers the majority of the functions in PHP. The others
are somewhat haphazard because it was not always obvious how to name
these given there was no underlying API to mimic.

So, whenever I see these, "let's just rename everything" posts, I never
see the fact that most of these functions are deeply ingrained in the
muscle memories of a lot of people addressed. And it is in our muscle
memories, not because of PHP, but because we still live in a world
written in C. As soon as you venture outside the world of PHP and
scripting languages, you hit this world.

That doesn't mean we can't try to address this, but simply renaming
everything is not the answer.

-Rasmus


--BufdcToq2MHfqsTKBVuxLjNKAQ29KwT24
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlLErcgACgkQlxayKTuqOuC9MwCeOhVJAxAi7AXXwyEmqHe4Fjm/
c/0An0FHhEA7J04ChasbuctNZBKYLJM7
=xyxM
-----END PGP SIGNATURE-----

--BufdcToq2MHfqsTKBVuxLjNKAQ29KwT24--