Paul M. Jones

"There are no solutions ... only trade-offs." -- Thomas Sowell

tl;dr: "As a library author it’s tempting to bring in dependencies for various reasons, but as a library user it’s frequently convenient to not have cascading dependency sets. ... If a user already has something they like, make it as easy as possible for them to keep using it without making them install things they don't actually need. That is the kind of duplication we really want to avoid. This applies not only to HTTP response delivery, but to caching, logging, translation, templating, and a host of other functionality."

Recent articles from me and others regarding the Aura project for PHP 5.4+, dependencies, and decoupling have generated a lot of commentary, some of it negative, and some of it misdirected. For reference, the posts are:

• How Is Aura Better Than (er, Different From ;-) Than Symfony and Zend?
• Aura: More Decoupled Than Symfony 2 and Zend Framework 2
• Aura.Micro: Experimental Replacement for Silex

In this post, I'll respond to some of that commentary. I will sum up similar comments and address those summaries.

Regarding "Dependencies Are Bad"

Bernhard "Webmozart" Schussek writes an otherwise good post that, unfortunately, begins by misconstruing my statements:

Aura is creating some buzz that components of PHP frameworks should not have any dependencies.

...

The general attitude of people arguing against dependencies is that dependencies are a bad thing.

Matt Robinson makes a related comment:

You’ve made a judgement call that dependencies should be avoided at all costs – I think that’s going a bit too far.

I can understand how some readers might infer the "dependencies are bad" sentiment from the interviews, especially if they did not read with thoughtful consideration. Their assessment is incorrect.

For the record: dependencies are not a bad thing in and of themselves, nor are they a good thing in and of themselves. Choosing to have one or more dependencies is a trade-off in software development, where the gains and losses from having the dependency must be judged according to the context of the development goals.

If dependencies are neither good nor bad in themselves, why does Aura avoid them so assiduously?

To learn the answer, please recall the origin of the Aura project (which is essentially the second major version of the Solar framework):

One of the repeated questions we got regarding Solar went like this: “I want to use just one part of Solar; can I do that without having to download and configure the whole framework?” Of course the answer to that was “not really.” It was a monolithic framework, where all the pieces were designed to work with each other in a relatively dependent fashion.

So with Aura, we started out from the other direction. We wanted the pieces to be usable on their own, without any other dependencies. Only after that would we build a framework out of the pieces.

As you can see, it is expressly our goal to serve a particular set of users as our primary focus: those who want independent libraries without added dependencies.

As a library author it's tempting to bring in dependencies for various reasons, but as a library user it's frequently convenient to not have cascading dependency sets. Call it a case of taking our audience seriously, and going as far as we can with it.

Regarding "Duplication"

Matt Robinson asks:

[W]hat’s the real difference between AuraHttpMessageResponse and AuraWebResponse? They look remarkably similar and have significant overlap in interface and purpose. I might be wrong, but it looks like you’ve got this big chunk of duplicated effort for the sake of avoiding one line in a composer.json file. :)

They are remarkably similar, since they serve a similar purpose; that is, to describe an HTTP response. I think "big chunk" is an inaccurate characterization, though; it's 2 classes out of 56 between both packages.

As Matt allows, he is in fact wrong. ;-) The duplication is not for the sake of avoiding one line in a Composer file. It is to make sure that people who want to use Aura.Web package are not required to additionally install the entire Aura.Http package to get access to a single class.

Many library users out there already have HTTP delivery mechanisms of their own choosing, and have neither the desire nor the inclination to drag another one into their codebase. All these users need is a way to describe an HTTP response. It's easy to do that in a single file.

Because of this single class of duplication that exists in Aura.Web, library users can build a relatively small amount of glue code to send the AuraWebResponse using their existing installation of Guzzle, Buzz, the HTTP extension, plain old PHP, or even the Aura.Http package. This is the tradeoff: a single duplicated file, versus many dozens of files of duplicated, unused, and unneeded functionality.

That is the central point for the Aura project: if a user already has something they like, make it as easy as possible for them to keep using it without making them install things they don't actually need. That is the kind of duplication we really want to avoid. This applies not only to HTTP response delivery, but to caching, logging, translation, templating, and a host of other functionality.

Stan, who admittedly is part of the Aura target audience, already knows this:

[T]here are some of us out there that have a hybrid of components tooled together. The more dependencies that are forced on us (guilty by assoc) the harder that is to do. So maybe my app that’s routed by Aura, templated by Twig, works with the DB using Doctrine ODM, utilizes Symfony for the Finder and Yaml components and Zend for the console could find itself in a pickle when more baggage is added to the mix through dependencies that might not be necessary.

Amy Stephen also figured out the point pretty quickly ...

Disagree with Paul’s assertion in the comments that such a strategy does not lead to some duplication of code or function or that the methodology means some functionality be sacrificed. Of course, it does. That’s the ying and the yang of it – get one thing clean and another dirty – the cost, time, quality triangle – It’s math. It’s always a balancing act building software.

... although to be fair, I didn't say "does not lead to some duplication"; I said duplicated code was "almost nonexistent." ;-) Perhaps that too was a mischaracterization: a few classes here and there, among hundreds of classes and a dozen packages, seems rather small to me. Others may disagree.

Regarding "Not Invented Here"

Some commenters claim that this approach promotes "NIH" syndrome. Drak said:

Seems to me like you are promoting NIH. The very concept that a decoupled component cant have dependencies means you have to invent everything yourself.

Webmozart similarly opined:

I think this needs some urgent clarification before this way of thinking becomes mainstream and PHP creeps back into its NIH-hole.

I would argue that the offering decoupled packages in the way the Aura does leads away from not-invented-here syndrome, not toward it.

Recall that one of the driving motivations behind Aura was to extract the parts of Solar that users wanted as separate packages. Those users wanted very badly not to engage in NIH by using Solar, but could not, because it was delivered as a monolithic whole. Those users can now download independent, decoupled Aura packages and avoid rewriting the functionality contained therein.

Bertrand lobbed a shot over the net at, I guess, the Symfony crowd, when he said:

Ha, ha, who’s got the NIH syndrom ?

Event_Dispatcher, written in 2005, 3 years before the one in your example...

http://pear.php.net/package/event_dispatcher

This is a comment I sympathize with. It seems to me that many accusations of NIH-ism are more complaints and frustrations that the accused is not using the libraries and packages the accuser prefers.

Regarding "Tests As A Way Of Discovering Dependencies"

Some 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. Webmozart said:

There’s a distinction between required dependencies and optional, supported libraries. For example, the Symfony2 Validator optionally supports annotations, in which case you need DoctrineCommon (why should it reinvent annotation parsing?). You can use the Validator without any of these supported libraries.

Obviously, the support for these libraries is tested, so for running the tests you also need the supported libraries (doh). I fail to see how this is bad.

Lukas covered this as well:

[T]he issue is that the way [Paul] was comparing. Paul was making a very incorrect conclusion that anything that is needed to run the tests illustrates “cross-package dependencies”. Yet if you look at the composer.json (which I would have expected Paul to be familiar with) then you would notice that infact the Validator component has ZERO dependencies beyond PHP itself:

https://github.com/symfony/Validator/blob/master/composer.json

This was a topic I had hoped I would not have to address. All my other statements regarding dependencies have been as clinical as I could make them, without reference to words like "good" or "bad" in describing the various practices. For this topic, though, I must make some statements that others will find negative or perjorative. Because of that, I am going to do it in an entirely separate post, so as not to pollute this commentary thread too harshly. Look for it in a few days.

Conclusion

Thanks to everyone for their comments and critique, and please be sure to check out the Aura project!

Late last night we released version 1.0.0-beta4 of the full-stack system, which composes all the independent Aura packages into a coherent framework using the Aura.Framework package in a project skeleton. We have extracted the “hello world” portions into their own Aura.Demo package so that it can be removed or disabled when you begin your project. Download it and take it for a spin!

via New System Release, Including Aura.Framework and Aura.Demo.

An affluent resident of an upper middle class town, Lanza had exactly the kind of resources that you would want for taking care of a kid with these kinds of problems. His parents had all the money he needed to get him help, and his school did everything they could to help him cope, according to the Wall Stret Journal: "Not long into his freshman year, Adam Lanza caught the attention of Newtown High School staff members, who assigned him a high-school psychologist, while teachers, counselors and security officers helped monitor the skinny, socially awkward teen, according to a former school official.

...

"Make more mental health resources available" or "early identification and treatment of troubled children" is a fine answer to many cases, but Adam Lanza had all that you could wish for in terms of resources.  It didn't stop him from picking up a gun and going to that school.  

What Lanza shows us is the limits of the obvious policy responses.  He had all the mental health resources he needed--and he did it anyway.  The law stopped him from buying a gun--and he did it anyway.  The school had an intercom system aimed at stopping unauthorized entry--and he did it anyway.  Any practical, easy-to-implement solution to school shootings that you could propose, along with several that were not at all easy to implement, was already in place.  Somehow, Lanza blew through them all.  

via There's Little We Can Do to Prevent Another Massacre - The Daily Beast.

Big news in pensions today: Silverdex, a major US-based conglomerate with fingers in just about every economic pie, from mining to solar cells, turns out to have been stuffing its main pension fund full of . . . it's own corporate bonds.  For decades.  It's still not clear how this happened without anyone noticing, but essentially the pensions that current workers have been counting on for thirty years turn out to be backed by nothing more solid than the company's promise to pay.  Amazingly, when confronted by reporters about this behavior, a representative declared that this was a big fuss over nothing.

"It is perfectly legal to invest a pension fund in corporate bonds.  That is what we have done.  These bonds are backed by the full faith and credit of Silverdex, and it is defamatory to suggest that they will not be paid."  

Silverdex is still pretty profitable after all these years, but "defamatory" seems absurd; obviously, it's quite conceivable that the firm will run out of money, and the workers will be left with no jobs, no pensions, and no retirement.  Though no charges have yet been filed, a congressional hearing is scheduled for next week, and observers expect high-level resignations from the Pension Benefit Guaranty Corp, which regulates pensions, to follow.  

I don't really know how to say this, but sorry, I lied a little bit.  I'm not talking about a private company at all, because of course, if a private company did this, it would be completely and totally illegal.  Regulators would have shut this down decades ago and probably at least a few lower-level executives would have spent a little time in the pokey.  Instead this is, of course, a description of how the United States Social Security "trust fund" works.

(Emphasis mine.) As usual, if a corporation did what the Federal government does, people would be howling for blood. But it's the government, so somehow it's OK. Via Assets in Name Only - The Daily Beast.

When every area of life becomes politicized, and political conversations are filled with elaborate terminology laced with virtually incomprehensible numbers, voters aren’t going to rush out and master macro-economics, or learn how to do math with ten-figure sums.  They’re going to decide which candidate they like more, and trust him to get everything right on their behalf.  Or, perhaps more pertinently given the nature of the 2012 contest, they’re going to back away from the candidate they dislike, and therefore distrust.  Those eyebrow-raising 100-percent-Obama voting districts in the 2012 election were cultural achievements, not the result of successful political arguments.

File under "politics is not about policy." Via Buying into the culture war | Conservative News, Views & Books.

Stan Lemon writes on the Aura Project for PHP 5.4+ blog about an experiment he's trying:

I was recently working on a small project that used Silex. As I browsed my vendor folder, I realized how much extra “stuff” I had inherited with Silex. There were a bunch of other components required when all I wanted was some quick and easy routing, micro-framework style.

When I think about going lean I always find myself coming back to Aura. Micro-frameworks are not a new to idea to Aura, so I wondered if I could take the elegance and ease of Silex by wrapping up Aura.Router and exposing it through a similar API. The result is Aura.Micro, a light wrapper for Aura.Router to get a Silex-style API.

Read the whole thing here: Aura.Micro -- Experimental Replacement for Silex.

Labor has two options now that its ability to extract mandatory dues from workers as a condition for employment is gone. It can fight the law or try to persuade workers to voluntarily pay up.

Union bosses aren't accustomed to the second approach, so until the next elections in 2014 they can be expected to try everything to overturn the law and to stop the right-to-work fever from spreading to neighboring states.

via Unions Begin Long War After Stunning Blow in Michigan - Bloomberg.

Video here: http://www.youtube.com/watch?feature=player_embedded&v=u_F3oev06i0

ASSAULTED BY UNION THUGS IN MICHIGAN. Crowder emails: “The video is self explanatory. I was sucker-punched 4 times on camera, without retaliation, choked, and the AFP tent is torn to the ground with women and children inside of it. Extremely violent footage. Please post for truth.” It’s also rich listening to the union guy yell about “parasites” and “freeloaders.” Don’t they know those words are racist?

The video shows numerous union representatives engaging in violent, illegal conduct. Their faces are clearly identifiable. I hope they will be prosecuted, and sued.

And will President Obama condemn this violent behavior?

If this was the Tea Party, it would be evidence of their violent extremist nature. Via Instapundit » Blog Archive » STEVE CROWDER SENDS THIS FOOTAGE OF HIM BEING ASSAULTED BY UNION THUGS IN MICHIGAN. Crowder emails:….

In a huge win for gun-rights groups, a federal appeals court in Chicago Tuesday tossed the state's ban on carrying concealed weapons and gave Illinois' Legislature 180 days to craft a law legalizing concealed carry.

"The debate is over. We won. And there will be a statewide carry law in 2013," said Todd Vandermyde, a lobbyist for the National Rifle Association.

In a split opinion, the 7th Circuit Court of Appeals reversed a lower court ruling in two cases downstate that upheld the state's longstanding prohibition against carrying concealed weapons.

via Big win for gun-rights groups: Federal appeals court tosses state ban on carrying concealed weapons - Sun-Times Politics.

The guys at PHPMagazin have posted a followup question about the Aura Project for PHP. Here is our original English conversation.

I'd like to follow up on the last point where we talked about other frameworks. I think that the second generations of symfony and Zend Framework have gone through a huge decoupling process. This becomes evident when you look at symfony2 components being used in Drupal 8 or web tutorials which show you mixed use of zend- and symfony components.

So I think we could elaborate further on that last bullet point we discussed. Does the above change your angle in this regard?

Not in this case. 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.

By way of comparison, let's examine something that ought to be relatively straightforward: input validation and filtering. We'll start with ZF2, then move on to Symfony2, and end with Aura. In each case, we will try to download the package and run its tests; this should be a good indicator of whether or not the package can be used independently. We will discover that you can't do it at all with ZF2, you can kind of do it with Symfony2, and that it's trivially easy with Aura.

Zend Framework 2

Let's start by downloading the ZF2 InputFilter package. It doesn't appear to be available for download by itself -- there is the main ZF2 repository at Github https://github.com/zendframework/zf2 but that's the whole framework, not just the InputFilter.

OK then, we can at least use Composer to incorporate the InputFilter into a project. We will set up a Composer file per the ZF2 instructions and install the InputFilter package. Our composer.json file looks like this:

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.zendframework.com/"
        }
    ],
    "require" : {
        "zendframework/zend-inputfilter" : "2.0.*"
    }
}

After downloading Composer into the same directory, we run the installer, and this is what we see:

$ ./composer.phar install
Loading composer repositories with package information
Installing dependencies
  - Installing zendframework/zend-stdlib (2.0.5)
    Downloading: 100%

  - Installing zendframework/zend-servicemanager (2.0.5)
    Downloading: 100%

  - Installing zendframework/zend-filter (2.0.5)
    Downloading: 100%

  - Installing zendframework/zend-i18n (2.0.5)
    Downloading: 100%

  - Installing zendframework/zend-validator (2.0.5)
    Downloading: 100%

  - Installing zendframework/zend-inputfilter (2.0.5)
    Downloading: 100%

zendframework/zend-stdlib suggests installing pecl-weakref (Implementation of weak references for StdlibCallbackHandler)
zendframework/zend-servicemanager suggests installing zendframework/zend-di (ZendDi component)
zendframework/zend-filter suggests installing zendframework/zend-crypt (ZendCrypt component)
zendframework/zend-validator suggests installing zendframework/zend-db (ZendDb component)
zendframework/zend-validator suggests installing zendframework/zend-math (ZendMath component)
Writing lock file
Generating autoload files
$

In order to use input filtering from ZF2, six other packages are required, and a few others are suggested.

Now that we've installed it, where are the tests? They're not provided with the Composer package, although I suppose they are available with the framework as a whole. It appears the Zend offering is not entirely self-contained.

(If we look closely, we see that InputFilter is composed of at least two other packages that might suit our needs, zend-filter and zend-validator. However, when you examine them, they're not comparable to Aura.Filter and Symfony2 Validator.)

Symfony 2

Let's do the same thing with Symfony. This time it is downloadable through Github: https://github.com/symfony/Validator

Let's clone the package and run the tests.

$ git clone https://github.com/symfony/Validator.git
Cloning into Validator...
remote: Counting objects: 3459, done.
remote: Compressing objects: 100% (672/672), done.
remote: Total 3459 (delta 2708), reused 3451 (delta 2700)
Receiving objects: 100% (3459/3459), 621.73 KiB | 730 KiB/s, done.
Resolving deltas: 100% (2708/2708), done.
$ cd Validator/Tests/
$ phpunit
[phpunit fails]

It appears we can't just download the package and run the tests. The README states we need to use Composer and install all the --dev dependencies, so we'll do that. First we download Composer into the cloned repo, then:

$ ./composer.phar install --dev
Loading composer repositories with package information
Installing dependencies
Nothing to install or update
Loading composer repositories with package information
Installing dev dependencies
  - Installing symfony/yaml (dev-master bed4fdd)
    Cloning bed4fddc24392513e01b32a78d600b1272ed9a6c

  - Installing symfony/locale (dev-master 2dceded)
    Cloning 2dcededb060dfb6289ad8bb3f2a7a4e00929c4dc

  - Installing symfony/http-foundation (dev-master 067c310)
    Cloning 067c310fe4d0691a24adc97f39500233a58e42cb

Writing lock file
Generating autoload files

Interesting: in order for the tests to run we need three other packages. It looks to me like there are cross-package dependencies. Examining the codebase reveals this to be true:

• If you want to use the YAML loader included with the Validator, you need that YAML package after all.

• If you want to validate against anything related to locales or languages, you need the Locale package. For example, the LangaugeValidator.php file makes a static call to SymfonyComponentLocaleLocale::getLanguages().

• If you want to use Annotations with the Validator, it looks like you need Doctrine, which isn't a part of the Symfony vendor hierarchy at all. Goodness knows what that will require.

Anyway, now we can run the tests; I have omitted the test progress output.

$ phpunit
PHPUnit 3.7.9 by Sebastian Bergmann.
...
Time: 8 seconds, Memory: 17.75Mb

OK, but incomplete or skipped tests!
Tests: 987, Assertions: 1091, Skipped: 12.
$

12 tests have to be skipped because of missing dependencies. When we run phpunit --verbose we discover that:

• 3 tests are skipped are because APC is not loaded for the command line, which is not such a big deal;

• 6 are skipped because "The Doctrine Common library is not available";

• 3 are skipped because "Annotations is required for this test".

As with the ZF2 InputFilter component, it looks like the Symfony2 Validator component is not entirely self-contained. It has external dependencies that must be fulfilled in order for it to be fully useful.

Aura.Filter

Finally, we have the Aura.Filter package. It is downloadable through Github at https://github.com/auraphp/Aura.Filter. Let's try to clone it and run the tests; I have again omitted the test progress output.

$ git clone git@github.com:auraphp/Aura.Filter.git
Cloning into Aura.Filter...
remote: Counting objects: 1105, done.
remote: Compressing objects: 100% (373/373), done.
remote: Total 1105 (delta 631), reused 1076 (delta 602)
Receiving objects: 100% (1105/1105), 725.94 KiB | 606 KiB/s, done.
Resolving deltas: 100% (631/631), done.
$ cd Aura.Filter/tests/
$ phpunit
PHPUnit 3.7.9 by Sebastian Bergmann.

Configuration read from /Users/pmjones/Aura.Filter/tests/phpunit.xml
...
Time: 4 seconds, Memory: 9.75Mb

OK (1009 tests, 1443 assertions)
$

No external dependencies, and nothing extra is needed for the tests to run. The package is completely self-contained, independent, and decoupled. Now compare the memory use and time taken to that of Symfony2: about half the memory used, and about half the time taken, to complete about 30% more assertions in the tests. (Incidentally, we have 100% test coverage of the source classes, but I don't know how that compares to Symfony and Zend.)

Conclusion

None of the above is to meant to say that Zend Framework or Symfony2 are poorly architected, not useful, or any other negative thing. They are good projects, and the components appear to be good too.

The only thing I am saying is that their offerings of separate components are not always very well decoupled. This is because they started with a framework and tried to extract pieces from it. (To be fair, some components from both of those projects really are dependency-free, but not all of them.)

But in Aura, with its "libraries first" approach, every package is truly decoupled, independent, and self-contained, with zero cross-package dependencies. That is the major difference I want to emphasize.