Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Loïc Faugeron:
Decouple from Frameworks
Oct 06, 2015 @ 09:48:23

In this recent post to his site Loïc Faugeron shows his support for a pretty common "battle cry" among developers that make use of one of the many PHP frameworks out there: decouple from your framework (including a few strategies how).

Frameworks solve infrastructure problems, for example how to create a HTTP or CLI application. While necessary, those concerns don't add any value to your project: the business need will not be fulfilled by creating an empty application. As always, different responsibilities mean also different reasons to change: frameworks have a history of Backward Compatibility (BC) breaks and they do so regardless of your project.

[...] Does that mean that we shouldn't use any frameworks? Should we just don't care and embrace fully frameworks? This article will explain how to avoid both extremes, by decoupling from the framework. It can be done by restricting the framework to its infrastructure responsibilities (HTTP, CLI), by only using its entry points (Controller, Command) and by using the Command Bus pattern.

He uses a simple application to illustrate his points, starting with a basic Symfony installation with PHPUnit and PHPSpec installed. He builds a listener to handle JSON encoded content input and sets up the initial "Quote" controller that will take in the new request. He follows the TDD mentality along the way, testing first then writing the code to match the test. With that system in place, he talks about the ideas of commands (from the "command bus" world) and how that could be used to refactor out the "submit" logic and make it less dependent on the framework it lives in. This lets the framework handle the low-level functionality (HTTP request/response, routing, etc) while the logic sits in a more abstract, contained location.

tagged: decouple framework opinion commandbus refactor encapsulate

Link: http://gnugat.github.io/2015/09/30/decouple-from-frameworks.html

PHP 10.0 Blog:
Kill resources
May 17, 2007 @ 07:56:00

In a new post to the PHP 10.0 blog today, Stas asks the question "Why do we still have resource type in PHP?"

Since 5.x, objects are perfectly capable on encapsulating any void * transparently (there's at least 2 Java bridges doing that, for example) and of course using objects doesn’t force you to use OO syntax. [...] So objects as I see it can do anything resources can do. And much more - you could extend it (had we had file as object and not resource, streams probably would be much easier to implement), serialize it (provided correct methods of course), etc., etc.

He suggests letting them go all together and letting objects swoop in and take over, making things simpler to manage.

tagged: resource type kill object encapsulate resource type kill object encapsulate

Link:

PHP 10.0 Blog:
Kill resources
May 17, 2007 @ 07:56:00

In a new post to the PHP 10.0 blog today, Stas asks the question "Why do we still have resource type in PHP?"

Since 5.x, objects are perfectly capable on encapsulating any void * transparently (there's at least 2 Java bridges doing that, for example) and of course using objects doesn’t force you to use OO syntax. [...] So objects as I see it can do anything resources can do. And much more - you could extend it (had we had file as object and not resource, streams probably would be much easier to implement), serialize it (provided correct methods of course), etc., etc.

He suggests letting them go all together and letting objects swoop in and take over, making things simpler to manage.

tagged: resource type kill object encapsulate resource type kill object encapsulate

Link: