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
