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 <[email protected]> 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
>
>