\n\n\"There are no solutions ... only trade-offs.\" -- Thomas Sowell
\n
tl;dr: \"As a library author it\u00e2\u0080\u0099s tempting to bring in dependencies for various reasons, but as a library user it\u00e2\u0080\u0099s 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.\"
\nRecent 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:
\nIn this post, I'll respond to some of that commentary. I will sum up similar comments and address those summaries.
\nBernhard \"Webmozart\" Schussek writes an otherwise good post that, unfortunately, begins by misconstruing my statements:
\n\n\nAura is creating some buzz that components of PHP frameworks should not have any dependencies.
\n...
\nThe general attitude of people arguing against dependencies is that dependencies are a bad thing.
\n
Matt Robinson makes a related comment:
\n\n\nYou\u00e2\u0080\u0099ve made a judgement call that dependencies should be avoided at all costs \u00e2\u0080\u0093 I think that\u00e2\u0080\u0099s going a bit too far.
\n
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.
\nFor 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.
\nIf dependencies are neither good nor bad in themselves, why does Aura avoid them so assiduously?
\nTo learn the answer, please recall the origin of the Aura project (which is essentially the second major version of the Solar framework):
\n\n\nOne of the repeated questions we got regarding Solar went like this: \u00e2\u0080\u009cI want to use just one part of Solar; can I do that without having to download and configure the whole framework?\u00e2\u0080\u009d Of course the answer to that was \u00e2\u0080\u009cnot really.\u00e2\u0080\u009d It was a monolithic framework, where all the pieces were designed to work with each other in a relatively dependent fashion.
\nSo 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.
\n
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.
\nAs 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.
\nMatt Robinson asks:
\n\n\n[W]hat\u00e2\u0080\u0099s 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\u00e2\u0080\u0099ve got this big chunk of duplicated effort for the sake of avoiding one line in a composer.json file. :)
\n
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.
\nAs 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.
\nMany 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.
\nBecause 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.
\nStan, who admittedly is part of the Aura target audience, already knows this:
\n\n\n[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\u00e2\u0080\u0099s 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.
\n
Amy Stephen also figured out the point pretty quickly ...
\n\n\nDisagree with Paul\u00e2\u0080\u0099s 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\u00e2\u0080\u0099s the ying and the yang of it \u00e2\u0080\u0093 get one thing clean and another dirty \u00e2\u0080\u0093 the cost, time, quality triangle \u00e2\u0080\u0093 It\u00e2\u0080\u0099s math. It\u00e2\u0080\u0099s always a balancing act building software.
\n
... 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.
\nSome commenters claim that this approach promotes \"NIH\" syndrome. Drak said:
\n\n\nSeems to me like you are promoting NIH. The very concept that a decoupled component cant have dependencies means you have to invent everything yourself.
\n
Webmozart similarly opined:
\n\n\nI think this needs some urgent clarification before this way of thinking becomes mainstream and PHP creeps back into its NIH-hole.
\n
I would argue that the offering decoupled packages in the way the Aura does leads away from not-invented-here syndrome, not toward it.
\nRecall 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.
\nBertrand lobbed a shot over the net at, I guess, the Symfony crowd, when he said:
\n\n\nHa, ha, who\u00e2\u0080\u0099s got the NIH syndrom ?
\nEvent_Dispatcher, written in 2005, 3 years before the one in your example...
\n\n
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.
\nSome 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:
\n\n\nThere\u00e2\u0080\u0099s 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.
\nObviously, 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.
\n
Lukas covered this as well:
\n\n\n[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 \u00e2\u0080\u009ccross-package dependencies\u00e2\u0080\u009d. 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:
\nhttps://github.com/symfony/Validator/blob/master/composer.json
\n
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.
\nThanks to everyone for their comments and critique, and please be sure to check out the Aura project!
\n" }![plain old PHP](\"http://image.slidesharecdn.com/decoupled-121201120108-phpapp01/95/slide-50-638.jpg\"){kind=link}