Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70973
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain yamiko.org does not designate 192.249.123.46 as permitted sender)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 02 Jan 2014 14:43:37 -0800
To: internals@lists.php.net
Organization: Yamiko LLC
In-Reply-To: <CACtwkeRnxQ-EjmYt7A=_z_qTnBErgOcXmEZ65o8et-CM_NxD_w@mail.gmail.com>
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> <52C510CF.3030604@garfieldtech.com>
 <0bae3e8fb5acff88a1aba0bea6bd264d@yamiko.org>
 <CACtwkeRnxQ-EjmYt7A=_z_qTnBErgOcXmEZ65o8et-CM_NxD_w@mail.gmail.com>
Message-ID: <e69e9ea9ef790022ef759443b3817522@yamiko.org>
User-Agent: Roundcube Webmail/0.9.3
Subject: Re: [PHP-DEV] [PHP6] Function name consistency
From: rparker@yamiko.org (Robert Parker)

On 2014-01-02 11:40, Tim Rhodes wrote:
> I've done PHP, C, Javascript, and C# for 15 years now. I greatly prefer
> PHP. Putting types,  classes and functions behind a namespace seems the
> most usable. Usually documentation is easier to understand since the
> related information is always behind a namespace.  Also using Pierre's
> "init_set('PHP5_FUNC_COMPAT',
> true);" to define the current functions (although the default should be
> true) would allow older code to work without changes. Moving to 
> namespaces
> would allow better consistent naming. Although this point can be moot
> because of IDEs, however it does force a developer to know what classes 
> and
> functions are going to be running in their application.
> 
> Moving strictly to an OO language would remove some of the easy for
> beginners to start and easy to prototype features of the language.
> 
> 
> Timothy Rhodes
> 
> 
> On Thu, Jan 2, 2014 at 11:49 AM, Robert Parker <rparker@yamiko.org> 
> wrote:
> 
>> On 2014-01-01 23:10, Larry Garfield wrote:
>> 
>>> 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
>>> 
>> 
>> I would consider myself one of those php developers. I know very 
>> little c,
>> and java. Javascript is my second language after php. Most php 
>> developers
>> have yet to move towards 5.3 and don't know how to even use namespaces 
>> or
>> what they are. They often use wordpress or drupal which are very slow 
>> to
>> adapt.
>> 
>> Considering how slow and hard it is for most php developers to migrate 
>> to
>> new versions of php I do not think creating aliases or changing the 
>> names
>> would be beneficial. Different developers would use different aliases 
>> and
>> it would confuse a lot of php developers.
>> 
>> IMO the best solution is to have more SPL objects in php 6. People can
>> either use the old functional php or the new OO php and the OO would 
>> have
>> more consistent names.
>> 
>> --Robert Parker
>> 
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>> 

I was not implying an OO only language. I love how php is not strictly 
OO. The point I was trying to get across is that most php developers 
will not adapt until unless they absolutely have too. Changing functions 
would be a huge deal to these people. using a tool is probably out of 
the question for them unless it was a gui based tool. Allowing different 
names would be confusing to them also. IDEs wouln't help IMO because 
they don't use them.

I have been using PHP for about 5 years and just started my career as a 
web developer. TBH I have only once meet someone who uses version 
control and knows what namespaces are. only a few people used an IDE or 
knew what an IDE was. I know there's a lot of great php developers out 
there but I do not think the make up the majority. Maybe it's 
demographics. I live in OR USA.

I think we should leave the functions as they are and include more SPL 
objects. The SPL would be more consistent for the people who do OOP.