PHP 7 makes life a lot better for PHP devs in many ways but one awesome thing is it obsoletes bunch of out-of-date tutorials by finally removing the old Mysql extension \o/
I actually met a young aspiring web developer who still learned DB-access with mysql_* functions. I urged him to switch to a sane framework like Laravel. Oh boy he was happy in a month and learned bunch of best practices quickly.
Been learning php on and off for a while, happy to see this release is out. Most likely I will use PHP for my future projects instead of the alternatives.
Languages are learning from each other these days, the new PHP definitely benefited from this trend and is actively evolving itself, which is the major reason I'm to stick with it.
Some PHP developers recommended nodejs over PHP for the future to me, after a few experience I feel PHP may be better for long-term maintenance. Renovation is good, it's just that javascript may have too much of it for me to chew on nowadays.
Wish there will be a light-weight version of PHP, something like micropython or Lua, so I can use it on low-end systems when needed. PHP is still very demanding on resources comparing to other languages, even nodejs can be used on IoT devices with restricted mem/cpu power.
Why do they keep adding global functions like "intdiv"? For example in JS, it being another language with a similar compatibility burden, they are moving most of the global functions (like parseInt) to "namespaces" (like Number.parseInt) while keeping global references there. When I open the docs (for example, the array functions page[1]), I get frightened by the global functions which do not seem to share a naming convention on first glance.
disclaimer: I haven't written anything significant with PHP since too many years.
This is ongoing in the PHP community. For those who like purity there are tons and tons of wrapper classes that hide all that stuff away.
Modern IDEs autocomplete all the functions, I'm using PHPStorm and as soon as I type 'arr' it shows me a list of all the array functions with parameters listed.
Not perfect, but if I was worried about that kind of thing I'd use Python (which I love) or RoR (which I also love).
When you put stuff in namespaces you need to remember in which namespace it is (and which library to refrence).
Number.parseInt is not that bad but I'll take to_json() global function instead of (new System.Web.Script.Serialization.JavaScriptSerializer()).Serialize() (or was it Newtonsoft.Json.JsonConvert.SerializeObject()?) any day.
Sure, names of PHP functions look arbitrary and inconsistent but when you know the name of the function you know everything you need (apart from how to use it which you can quickly and unambigously check like: http://php.net/file_get_contents )
All the existing math functions are global. If you add a new one, it's only fitting that it is global too. Having one and only one math function namespaced would be inconsistent.
I wish every PHP developer would reread the docs and start using new features available instead of just continuing with what they know already just because it works. And of course if there was any way to remove all those old tutorials out there.
And every php developer would wish that suddenly all php in the world upgrades to v7. We are years away from 7 having a big penetration in the ecosystem. And years more till it hits enterprise.
I doubt any of those developers are ever going to switch what they're already using unless they are forced by some external factor.
The more serious factor is: if you're on Hackernews, you're at least Elvis or even Einstein. Mort is out of reach for most internet media for programmers.
The performance improvements in this release will hopefully encourage people to upgrade, even if the new features don't. Common PHP applications run 70%-100% faster on PHP 7 than they did on PHP 5.6, comparable with or better than HHVM.
The performance increase is what I'm looking forward to most with 7. I can't wait to see how several of my code-heavy WordPress installations do with 7. From the benchmarks I've seen, it's going to be incredible.
Specifically, I'm hoping the page load times will be cut in half.
I was so excited when I saw this post. Then I realized it's another 'too early' post claiming the tag == release. It's not released until it happens on the PHP site. This is just a tag in the repo. Sure, it likely won't change now, but it could.
Probably one of the biggest releases since 5 in my opinion. Scalar and return type declarations being added in are a couple of massive additions. For a language that used to cop a lot of flak, PHP sure has grown to become a mature and quite decent language.
The scalar and return types are really a great improvement IMHO, I can't wait for Doctrine to fully support it for code generation.
But one thing which is missing is the nullable types, as currently it's either you always return a string and you can use scalar typing, or you sometimes return null and you can't use it (which I'm okay with)
The one thing I'd love to see is a native concurrency story with PHP. I'd put my vote in specifically to have Communicating Sequential Processes. I think that feature alone would take the language to another level. I know they've got stream_select, et al. and I've really enjoyed pecl event, reactphp, and of course there's HackLang's Async / Await if you want to convert, but having some modern / native constructs would be nice to have. Does anyone know if that's on the horizon?
PHP has pthreads which are slowly becoming a real thing. There are a few relatively non-minor stumbling blocks in the way, but I imagine that it'll be only 12-18 months between when it can be a priority and when it'll be part of PHP. I expect you'll be able to do true concurrency in PHP in the next ~3 years.
Congratulations to the PHP community with this milestone!
I wonder if people who switched to HHVM, will start using PHP again. HHVM has offered much faster performance than previous versions of PHP. The speed of PHP 7 is at par with HHVM.
HHVM is still a bit faster than PHP7 in most benchmarks (wordpress, etc.). HHVM has also JIT and consumes less memory per request. Though PHP7 is more backward compatible with real word PHP5 code bases and is easier to install.
> The server running pear.php.net had a fatal hard disk failure and gets replaced by a new machine this week. Until the new machine is setup, this page is up to let you continue installing PEAR packages via the PEAR installer.
Have been waiting for this anxiously. I've been running a few test builds on it occasionally, but its nice to have the guarantee to shift prod systems to it.
To me, PHP is still interesting, because of the ProcessWire CMS/CMF [1], which is basically the next best thing afte sliced bread (A generic hierarchical content structure, with a jquery-inspired PHP template API, giving FULL flexibility to customize your design and presentation to anything you like ... even REST apis are just a few lines of code in a template. Add to that dozens of dozens of extremely nicec features built in, such as automatic thumbnail resize through API methods such as <img src="{$image->size(90,90)->url}"> ... and you have something immensely powerful).
Of note: that issue has been ongoing for months, and most of the issues that were found were fixed in PHP core within a few days/weeks. Drupal 8's test suite even caught one regression that delayed the PHP 7.0.0 final release a few weeks!
Most modern PHP apps will work on PHP 7.0.0 with little or no extra effort, but if you have a large legacy app, and haven't ever turned on error logging, you may need to fix a bunch of deprecated code usage!
It really does. I work partly on a 10 year old PHP software. PHP 7 has apart from some other breakages some changes in the evaluation order that I expect to break everything. Thankfully related to objects, so with a bit of luck it will mostly hit the bundled libs (the project of course does not use objects for its own structure) which can then be exchanged or maybe will get updates.
When years ago I started learning Ruby and wanted to use it for the web, my intention was using it like you do with PHP (simply including it in HTML) but I got a bit frustrated because all the resources I kept finding showed the only way of using Ruby in a web context was by using a big framework like Rails or, by choosing a wrong path and playing with stuff which required a lot more in depth knowledge that I did not have (and that I didn't want to be forced to have because I just wanted to focus on app code and experiment).
I only recently discovered https://github.com/migrs/rack-server-pages which allows to simply shove Ruby in HTML the same way as PHP and as a new Ruby dev could expect to be able to do. I think this approach makes learning projects simpler, and at the same has the added value of making people actually learn a lot about those aspects of HTTP that frameworks keep well hidden under their carpet and that can help you become a good web developer instead of "simply" a framework user.
Yes for sure, best practices that frameworks implement are there for a reason, and it's great to have them, but IMHO, this approach has advantages when learning and could also be seen as an essential step to understand what those frameworks you will use next are abstracting and why.
IMHO, what still contributes to new generations of devs approaching PHP, is also its immediateness and simplicity with nothing to do except '<?php' code '?>' and with this comment I just wanted to give a bit more exposure to the fact that a similar solution exists for Ruby too, and that it's a bit of a pity that because of the importance of Rails it got a bit overshadowed.
[+] [-] trm42|10 years ago|reply
http://php.net/manual/en/migration70.removed-exts-sapis.php
I actually met a young aspiring web developer who still learned DB-access with mysql_* functions. I urged him to switch to a sane framework like Laravel. Oh boy he was happy in a month and learned bunch of best practices quickly.
[+] [-] Flimm|10 years ago|reply
[+] [-] ausjke|10 years ago|reply
Languages are learning from each other these days, the new PHP definitely benefited from this trend and is actively evolving itself, which is the major reason I'm to stick with it.
Some PHP developers recommended nodejs over PHP for the future to me, after a few experience I feel PHP may be better for long-term maintenance. Renovation is good, it's just that javascript may have too much of it for me to chew on nowadays.
Wish there will be a light-weight version of PHP, something like micropython or Lua, so I can use it on low-end systems when needed. PHP is still very demanding on resources comparing to other languages, even nodejs can be used on IoT devices with restricted mem/cpu power.
[+] [-] egeozcan|10 years ago|reply
disclaimer: I haven't written anything significant with PHP since too many years.
[1]: http://php.net/manual/en/ref.array.php
[+] [-] monk_e_boy|10 years ago|reply
Modern IDEs autocomplete all the functions, I'm using PHPStorm and as soon as I type 'arr' it shows me a list of all the array functions with parameters listed.
Not perfect, but if I was worried about that kind of thing I'd use Python (which I love) or RoR (which I also love).
The ethos of PHP is to just get stuff done: http://axonflux.com/5-quotes-by-the-creator-of-php-rasmus-le...
[+] [-] scotty79|10 years ago|reply
Number.parseInt is not that bad but I'll take to_json() global function instead of (new System.Web.Script.Serialization.JavaScriptSerializer()).Serialize() (or was it Newtonsoft.Json.JsonConvert.SerializeObject()?) any day.
Sure, names of PHP functions look arbitrary and inconsistent but when you know the name of the function you know everything you need (apart from how to use it which you can quickly and unambigously check like: http://php.net/file_get_contents )
[+] [-] TazeTSchnitzel|10 years ago|reply
[+] [-] debacle|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] RohithMeethal|10 years ago|reply
[+] [-] venomsnake|10 years ago|reply
[+] [-] oblio|10 years ago|reply
I doubt any of those developers are ever going to switch what they're already using unless they are forced by some external factor.
The more serious factor is: if you're on Hackernews, you're at least Elvis or even Einstein. Mort is out of reach for most internet media for programmers.
[+] [-] longwave|10 years ago|reply
[+] [-] MichaelApproved|10 years ago|reply
Specifically, I'm hoping the page load times will be cut in half.
[+] [-] Kartificial|10 years ago|reply
[+] [-] lsaferite|10 years ago|reply
[+] [-] DigitalSea|10 years ago|reply
[+] [-] maweki|10 years ago|reply
[+] [-] sneak|10 years ago|reply
[+] [-] allan_s|10 years ago|reply
But one thing which is missing is the nullable types, as currently it's either you always return a string and you can use scalar typing, or you sometimes return null and you can't use it (which I'm okay with)
https://wiki.php.net/rfc/nullable_types https://github.com/php/php-src/pull/1045
With this, it will permit to have even better static analysis "a la" HHVM/hack (i.e detecting that you haven't check for is_null in your code
[+] [-] cdnsteve|10 years ago|reply
- Type declarations (this is a HUGE move forwards).
- Grouped use statements, not sure if I like how that looks
- ?? will shorten statements
- Anonymous classes seem a bit odd looking to me
- Unserialize filter is a nice security bump
Anxious to try it out and see the speed improvements I've been hearing about too.
[+] [-] mjrpes|10 years ago|reply
https://wiki.php.net/rfc/anonymous_classes
[+] [-] datashovel|10 years ago|reply
[+] [-] debacle|10 years ago|reply
[+] [-] defenestration|10 years ago|reply
I wonder if people who switched to HHVM, will start using PHP again. HHVM has offered much faster performance than previous versions of PHP. The speed of PHP 7 is at par with HHVM.
[+] [-] mtbcoder|10 years ago|reply
[+] [-] castell|10 years ago|reply
[+] [-] motiejus|10 years ago|reply
"build error".
Wait, what? You just released it, it should definitely work! Clicking that icon[2], checking the failed build[3]:
ERROR: no certificate subject alternative name matches
requested host name `pear.php.net'.
To connect to pear.php.net insecurely, use `--no-check-certificate'.
Really? See what's in http://pear.php.net/
> The server running pear.php.net had a fatal hard disk failure and gets replaced by a new machine this week. Until the new machine is setup, this page is up to let you continue installing PEAR packages via the PEAR installer.
In 2015? Cool.
Connecting to the https website ...
% openssl s_client -connect pear.php.net:443 ... Certificate chain 0 s:/CN=mail.cweiske.de
So you're using CN=mail.cweiske.de for pear.php.net. I don't even know what to say.. Well, happy hacking!
[1]: https://github.com/php/php-src [2]: https://travis-ci.org/php/php-src [3]: https://travis-ci.org/php/php-src/jobs/94372493
[+] [-] untog|10 years ago|reply
[+] [-] jhall1468|10 years ago|reply
Do you actually think there's a point in time where mechanical hard drives are going to last forever? If so I have a bridge to sell you.
[+] [-] wtetzner|10 years ago|reply
>So you're using CN=mail.cweiske.de for pear.php.net. I don't even know what to say.. Well, happy hacking!
Yeah, but it's cool that they used Let's Encrypt.
[+] [-] sarciszewski|10 years ago|reply
[+] [-] captn3m0|10 years ago|reply
New Features list is at https://secure.php.net/manual/en/migration70.new-features.ph...
My favorite is scalar typehinting by far.
[+] [-] almsgiver|10 years ago|reply
[+] [-] samuell|10 years ago|reply
[1] http://processwire.com
[+] [-] cdnsteve|10 years ago|reply
[+] [-] geerlingguy|10 years ago|reply
Most modern PHP apps will work on PHP 7.0.0 with little or no extra effort, but if you have a large legacy app, and haven't ever turned on error logging, you may need to fix a bunch of deprecated code usage!
[+] [-] onli|10 years ago|reply
Lots of work.
[+] [-] randomname2|10 years ago|reply
[+] [-] MrBra|10 years ago|reply
I only recently discovered https://github.com/migrs/rack-server-pages which allows to simply shove Ruby in HTML the same way as PHP and as a new Ruby dev could expect to be able to do. I think this approach makes learning projects simpler, and at the same has the added value of making people actually learn a lot about those aspects of HTTP that frameworks keep well hidden under their carpet and that can help you become a good web developer instead of "simply" a framework user.
Yes for sure, best practices that frameworks implement are there for a reason, and it's great to have them, but IMHO, this approach has advantages when learning and could also be seen as an essential step to understand what those frameworks you will use next are abstracting and why.
IMHO, what still contributes to new generations of devs approaching PHP, is also its immediateness and simplicity with nothing to do except '<?php' code '?>' and with this comment I just wanted to give a bit more exposure to the fact that a similar solution exists for Ruby too, and that it's a bit of a pity that because of the importance of Rails it got a bit overshadowed.
[+] [-] jafingi|10 years ago|reply