php[architect] magazine has published their latest edition - the June 2016 issue, Decoupled by Design.

The June 2016 issue of php[architect] magazine is now available! Less tightly coupled code is easier to debug and re-use. This month we look at techniques to decouple different aspects of your code: including using asynchronous & distributed workers, transducers, middleware, and secure web services.

The issue includes articles like:

• "Security Architecture: Securing your Web Services, Part Two" (Edward Barnard)
• "The Middleware Awakens" (Ian Littman)
• "MySQL’s JSON Data Type" (Dave Stokes)

...as well as several of the usual columns sharing community and professional development tips. If you're not a subscriber and want a sampling of the content, be sure to check out the free article for this month covering video manipulation with FFmpeg. You can also pick up a subscription directly from the php[architect] site if you want to read more.

In this new post to his site Paul Jones talks a bit more about coupling in frameworks (see some of his recent Aura posts for more), this time looking at how the Symfony framework defines "decoupled" based on its object structure.

Previously, on decoupling and dependencies, I said: “Some [Symfony] commenters were dissatsifed with my use of unit testing requirements to discover what a package really depends on, as opposed to what its composer.json file states.” I’m willing to allow that the Symfony commenters here might be right. Let’s try looking at Symfony’s claims and see how they stack up.

Based on a list of components Symfony says don't have mandatory dependencies, he finds that - out of the fifteen given - four of them do have dependencies.

Does having mandatory dependencies make it a bad project? Not at all. It just means their statement of “no mandatory dependencies” (and related statements) is not true for all the components listed. Now, it may be that the Symfony folk have a different idea of what “decoupled” and “standalone” mean.

In response to the number of questions (and popularity) of his previous information about the Aura framework and how it compares to Zend Framework 2 (and Symfony2), Paul Jones has posted more about its decoupled nature and how the frameworks compare.

Being able to use Symfony2 components or ZF2 modules is not quite the distinction I am making. The distinction is that all Aura packages (with the exception of the Framework package) are completely independent, and have no cross-package dependencies, whereas at least some of the components from Symfony2 and ZF2 have dependency requirements.

He illustrates the point with a common task across all of the frameworks - input validation and filtering. He starts with a look at how to handle it in Zend Framework 2 (with Zend/InputFilter) with the list of packages also pulled in by the Composer install. He does the same with the Symfony2 "Validator" package and mentions the other packages needed to execute its tests. Finally, he looks at Aura's "Aura.Filter" component and it's lack of dependencies (and that its tests can be executed immediately).

Lukas Smith has a new post sharing what he sees as a growing trend in the development of PHP applications (a good thing) - the decoupled mindset more developers seem to follow and the use of tools like Composer that help to promote it.

As more and more projects adopt composer they will not only start using 3rd party code, they will also come to realize how easy it is for them to expose their code to 3rd parties. Obviously NIH syndrome will not be purged from the planet and maybe it should never get purged entirely anyway. But its already quite clear how much the landscape of the PHP community is changing with Symfony2, Doctrine, Zend Framework2, TYPO3 and many other projects having adopted composer.

He notes, however, that there still seem to be those clinging to "the old ways" and keeping things tightly bound to the technologies they're designed to work with. He's coming from the point of view of a Symfony2 user, so he gives the examples of some of the Bundles that are out there, reinventing functionality they could have pulled in from 3rd party libraries.