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