PHP 5.5 released and other things PHP related | Hacker News Reader

PHP 5.5 released and other things PHP related

phpweekly.com

47 pointsinovica41 comments

Open articleView on HN

Changelog here: https://github.com/php/php-src/blob/php-5.5.0/NEWS

Highlights:

* Opcode cache (https://wiki.php.net/rfc/optimizerplus)

* Generators and coroutines (https://wiki.php.net/rfc/generators)

* "finally" keyword

* Constant array/string dereferencing

* Optimized access to temporary and compiled VM variables. 8% less memory reads.

* Dropped Windows XP and 2003 support.

I've never used Optimizer+ so I might have to compare it with my nginx/php5-fpm/apc buildouts.

I understand compiling bytecode to memory but I still wish there was a way to write files bytecode files back to the disk in a similar fashion to python.

Ww also have a modern framework for php. Everyone should try http://laravel.com/ , such a fresh air into php development.

Or at the very least just learn how to use Composer.

Agreed! Framework arguments aside, learn how to use Composer. If you haven't played with namespaces, this is a great way to start learning more about them and using them in your own codebase. It also makes it incredibly easy to work with other packages[1]!

[1] https://packagist.org/

We just implemented an internal composer repository for sharing code between our different services. I am surprised composer isn't more popular. I have been developing for a long time and have only recently heard of it.

Silex is better , i hate all these static classes everywhere. That's the only reason i'm not using Laravel "Core" . Eloquent is nice though.

Hmm, every new framework nowadays seems to be based on Symfony2 which appears to be kind of slow.

Is there any small (relatively new) PHP framework that isn't based on Symfony2?

probably not what you're looking for but maybe slim framework? http://www.slimframework.com/

4bytes is crazy fast: https://github.com/donutdan4114/4bytes-framework

Silex and Laravel don't really serve the same purpose. I think both have merits, and it's hard to say a micro-framework like Silex is "better" than a full-featured framework like Laravel, unless you're applying a specific context..

No static classes, they are facades.

I have mixed feelings about Laravel's use of the facade pattern. On one hand it brings a really simple API, which is great for new users and rapid development. On the other hand, it's hiding away dependencies and making testing slightly more complex. It's seems a bit like hiding behind multiple global service locators.

What about phalcon (http://phalconphp.com/)? Which reminds me of two things:

[] TechEmpower Benchmark Round 6 was due today, but it was re-scheduled to the 25th [] Symfony should remove High Performance from their homepage title.

Phalcon is well done. I've been going through it recently and it will become my preferred mini-framework of choice.

React (http://reactphp.org) is nice if you want to do real-time or websocket stuff. Also supports asynchronous Redis, ZeroMQ, and DNS queries.

I would love to see an asynchronous database client (for instance Mysql) for it, but for now I use PDO.

If you need a control panel for the nifty new Zend Opcache in PHP 5.5, please steal my ugly hack and improve it: https://gist.github.com/ck-on/4959032

You should put this into a regular repository so that people can send pull requests.

> All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository.

But they do not (yet?) support pull requests, so you end up with a number of disparate forks.

This is the latest PHP weekly. With PHP 5.5 just being released today we cover this and other news related to PHP.

One other thing - Send us announcements, blog posts, news etc and we'll include them

The SaaS article uses mysql_query() and the top 10 framework post has an annoying Facebook modal and offers very little content.

I don't normally look at most of the articles, but the ones I do read are usually decent!

One step closer to launching mysql_query into the sun.

why is mysql query bad? as someone who knows sql, I've always loathed over abstracted mechanisms for db calls.

its also been a while since I've done web dev.

The old php mysql_* functions have become notorious for their vulnerability to SQL injection[1].

In no small part because novice developers also have a tendency to build queries directly out of $_GET parameters.

While PDO and parameterized queries aren't a silver bullet, simple strings as queries are just a nightmare to do properly.[2]

[1] http://stackoverflow.com/questions/60174/how-to-prevent-sql-... [2] http://www.youtube.com/watch?v=o4dJ7hdA8fs

It's an unmaintained extension that does not support new MySQL functionality. If you don't want any more abstraction you can use the mysqli_* functions instead.

If you forget to escape even one bit of supplied user data your entire application, server, or possibly even business can be compromised. You need to be extremely disciplined about escaping if you use this antiquated method. There are automated injection tools that will discover and exploit these, it's not even hard.

All you need to do is use a database layer with placeholder values and if you're diligent about encoding everything that way, your chances of being hacked by a simple SQL injection bug are nearly zero. You'll have to make several mistakes before you're in hot water.

`mysql_query` is the worst possible interface to MySQL since it's literally the low-level C bindings ported in to PHP without any kind of enhancement. Those functions were intended for writing more abstract interfaces, not being used directly.

While it is possible to write mysql_query code correctly, it is very challenging and not worth the time when facilities like PDO exist.

Also, if you loathe "over abstracted" database libraries you're probably using the wrong library. A library should make your database interfacing easier, not harder.

Signed up 2 weeks ago. Keep up the good work

Same here, pretty good advanced in-depth content.

>open changelog

>ctrl+f "PSR"

>0 results

Into the trash it goes.

Wow, PSR-2 (Coding Style Guide) seems fairly extreme (existentially, not in it's specifics which I haven't looked at) for PHP.

Part of me thinks it's odd, considering I never felt all that much freedom to change how I expressed things in PHP (at least not in the slightest compared to Perl).

Another part of me thinks that enough amateur programmers use PHP that some style guide may benefit them greatly. Then again, if people don't come to a better style through experience (or at least an explanation of the benefits or what mistakes it helps prevent) then is it really as useful?

The purpose of the PSRs is to help support and foster collaboration between members of the Framework Interoperability Group (the people who draft and publish the PSRs: consists of medium-to-large PHP projects including Symfony, Amazon, Drupal, Joomla, etc.). Having a common coding standard makes it much easier to publish code as part of other PSRs as questions like "tabs or spaces?" don't have to get rehashed every time a new PSR is drafted.

That's to say PSR-2 is not intended to a be a "best practices" type of thing: it's actually just the result of a survey of member projects at the time with each part chosen because that's what the majority of them did, even if it was just a simple majority or there were member projects were with the majority on, say, tabs vs. spaces but not, say, indentation size. Some of the FIG member projects have adopted it, but several haven't and don't intend to. It's useful if you don't have any other coding standard available, but easily ignored with no loss of interoperability with the other PSRs if you do.

Thanks for the explanation, that makes more sense.

Why would coding guidelines for PHP projects be in the language's changelog?

PSR-0 is widely adopted by anything relevant in the PHP ecosystem. Sure, those style guides might not be pitch-perfect but it is time for PHP to step it up and get some uniformity in their codebase. _At least_ adopting PSR-0 would have been a great step towards that.

Uncertain why I am getting downvoted for this (top parent) it is my personal opinion and just because you think otherwise isn't a valid reason.

Why would you expect a C project to use a PHP style guide?

How does the PHP project adopt PSR-0? PSR-0 is a standard for programs written in PHP; what would they do to adopt it that is in anyway better than the current situation?

Part of PSR-0 is a standard for autoloading namespaced classes, so, if you write you're own autoloader, implementing PSR-0 is neccessary to support loading libraries using that standard.

The situation before PSR-0 was a mess of different, incompatible directory layouts for loadable libraries.

> At least adopting PSR-0 would have been a great step towards that.

PSR-0 is broken on machines using filesystems that aren't completely case-sensitive.

Implementing PSR-0 also takes about five lines of code. Sure, it's more boilerplate, but it's not something that needs to be in core.

PSR-0 doesn't really apply to C code. Also, php-src has had coding standards that really haven't changed for years: https://github.com/php/php-src/blob/master/CODING_STANDARDS

Reply on news.ycombinator.com