Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70951
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
Message-ID: <52C510CF.3030604@garfieldtech.com>
Date: Thu, 02 Jan 2014 01:10:07 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: 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> <52C4ADC8.1090009@lerdorf.com>
In-Reply-To: <52C4ADC8.1090009@lerdorf.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PHP6] Function name consistency
From: larry@garfieldtech.com (Larry Garfield)

On 01/01/2014 06:07 PM, Rasmus Lerdorf wrote:
> 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?
>> You make it sound like such a redesign is an obvious and achievable goal
>> for the next "major" release of PHP. Neither PHP 5 nor the abandoned PHP
>> 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.
>>
>> 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?
>>
>> 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

Rasmus, I know you've made this point many times and it is valid 
historically, but I am not convinced it's valid in the day to day 
practice of most PHP developers.  Only a tiny fraction of the PHP 
developers I know have any knowledge of C, POSIX, etc., and I think all 
of them are on this list (or were until recently).  While it's great 
that, for example, ext/mysql is virtually identical to The MySQL C APIs, 
that is really no consolation for someone who has never looked at (nor 
needed to, nor had any desire to) the MySQL C bindings.

I'm pretty sure most PHP developers' second language isn't C; odds are 
it's Javascript, and after that either Python or Ruby.  (I have no firm 
data to back that up; it's just my gut feeling based on the developers I 
interact with across the community.)

I agree that "rename all the things" doesn't help, for BC reasons if 
nothing else; even with huge language improvements in a major version, 
it still needs to be possible to run well-behaved code across several 
contiguous versions or adoption will be nil.  That means strlen(), 
strrchr(), etc. are not going anywhere.

What I'd suggest instead, and I am not the first to suggest, is to leave 
the existing functions in place; let them be happy.  Then in 
PHP.nextMajor (whatever that is), add new well-developed, thought-out, 
probably OOP, namespaced routines for strings, arrays/collections, etc.  
Those should be based on trends, standards, and conventions that are not 
older than half the people on this list.

Replacing \strlen() with \string_length() has no real value, I agree.  
However, (as an example) offering

$string->length()
"some string"->length()
$iterable_including_arrays->map(function($a){})->filter(function($a) {});

now that's worth doing, and worth making big changes for.  But that 
can/should be done without touching any of the existing functions, 
because we don't want to break BC there for userspace code.  If one 
method happens to internally sub-call to the other in the engine, meh, I 
don't care and neither does anyone else in userspace.

--Larry Garfield