>On Thu, Jan 2, 2014 at 11:43 PM, Robert Parker <[email protected]> wrote:
> 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 <[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
>>>
>>>
>
> 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.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
(This not PHP specific nor it's targeted any specific person or group)
So, the argument of having a bad language is that if the people who
use it are bad then it should stay bad forever? Shouldn't a language
strive to be better and better, promote good practices and enhance the
way people program not just write code?
And if it's that hard to run "php -5to6 /path/to/file.php" then I
guess one needs to wonder if he's really in the right business. Yes,
you may have a tool that is using some fancy interface, but CLI itself
is also a GUI on it's own.
Maybe making the whole thing consistent is coming a bit too late now
in the game, at least for old stuff and considering the spread of PHP
there's going to be lots of people frustrated about changes. Something
like this shouldn't be treated lightly nor should it be done without a
form of automated migration (again, engine support is not that
solution). But on the other hand, sticking to a solution because it's
yours or because you got accustomed to it it's not something a
programmer should do either.
As for PHP6 to come to life and be adopted, besides a single 'oh look,
PHP6 is here with all the functions renamed / parameter shifted
around' it has to come with more then that, HHVM integration is a good
start, seeing how it's holding pretty well in benchmarks and finally
it's being considered as something that might be looked into in the
future, something that a year ago was a: 'oh no, no'.
Regards,
Florin
----
Florin Patan / @dlsniper
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan