Paul M. Jones

In a tweetstorm that spun up late last week, Taylor Otwell produced the following commentary:

look guys I’m “decoupled” because this package doesn’t have composer dependencies!!! HAHAHAHA LOL

how many composer packages a given package has does NOT affect YOUR code’s decoupling.

that is a matter of programming to an interface, etc.

you people seriously do not understand decoupling. at all.

if you type hint AuraAnything that is a HARD, CONCRETE dependency. THAT is coupling.

IlluminateContracts are all interfaces. abstractions. not concretions. THAT’s decoupling.

IlluminateContractsViewFactory could be a Laravel view factory, could be an Aura one. That’s decoupling.

how many composer pkgs the IMPLEMENTOR needs is an implementation detail my consuming code need not care about

consuming code ONLY cares about programming to an interface for decoupling.

you [@philsturgeon] and brandon [savage] and paul [jones] don’t understand basic programming concepts like coupling

and think somehow coupling is tied to composer

Aura ships hard concretions = you are tightly coupled to Aura.

which should my consuming code give a shit if Aura is decoupled AMONGST ITSELF. Nobody gives a shit.

i only care if MY code is coupled to Aura.

and since Aura makes you depends on hard concretions, it promotes hard couplings.

I’m saying if you type-hint a class dependency, you are coupled to that implementation (cont)

regardless of that package’s internal dependencies

While some of Taylor’s rant is correct for as far as it goes, much of it glosses over important distinctions in subtle misdirection, and the remainder displays some misunderstandings. He is also flat wrong in his assertions of other peoples’ understanding of “basic programming terminology.” As such, I think his words demand a careful response for future reference.

First, I’m glad to see Taylor paying attention to the proper use of terminology in a software context. This is something he’s not always been great at in the past, and I encourage him here.

But I can’t quite tell if Taylor thinks the developers who use Aura believe their code is decoupled by virtue of using Aura. Or maybe it’s that the Aura marketing phrase “fully decoupled libraries” is the target of his ire. I infer allusions to both from his tweets, so I’ll attempt to address both possibilities. (Perhaps there is some other interpretation I have missed.)

It should be so obvious as to not require stating, but for the sake of explicitness: If your code has a dependency on classes in a particular thrid-party package, your code is tightly coupled to the code in that package. This is true for any classes in any library, framework, or other package code. So, if you believe that depending on an Aura library in your code makes your code “decoupled” then you are mistaken. As far as I know, I have never attempted to state or imply otherwise. I don’t think any Aura users have this misperception, but if so, consider this a corrective.

The fact that your code could be tightly coupled to another package does not mean that the other package is coupled to anything else. That is to say, the other package might have no couplings of any sort to any other code outside itself. The other package in that case is de-coupled.

The Aura library packages are designed with that kind of decoupling in mind. That is, no Aura library package depends on anything at all in any other Aura package. Each of the Aura libraries is thus fully decoupled from the others, and incidentally from any framework that is composed of them. (Note that the *_Kernel and *_Project packages are coupled to other packages; the decoupling principle applies only to the Aura library packages.)

But why would you care if a particular library package is itself decoupled from other packages? I assert that one reason (of many) you want libraries that are themselves decoupled is so that, if you have to swap one out in your own code, you only have to worry about the one library, not about all the dependent libraries that it is coupled to (and all the dependent libraries they are coupled to). Swapping out is still tedious: you will need to work through your code, change all the typehints from that library’s classes to those in another, and change all the injections that specify classes from the library. But at least it’s only the one library; the fact that the library is itself decoupled reduces the swapping-out work.

Taylor points out another level of coupling called “loose” coupling. This means that, instead of your code depending on a particular class, you instead depend on an interface. This couples you to the interface, but not to any particular implementation. If your code depends on interfaces, your code is loosely coupled to the implementations of those interfaces (although I don’t think this means you are de-coupled – there’s still some knowledge necessary for interactions).

Being loosely coupled is a good situation to be in compared to being tightly coupled. If you need to swap out an implementation of an interface, you won’t need to change your typehints (unless you swap to another set of interfaces). However, you will still need to change all your injections to the new implementation. Overall, being loosely coupled makes for less work when swapping out libraries.

How can you tell if a package is coupled to another package? Provided that composer.json is not lying, it’s easy enough to examine the “require” element to see if there are other packages listed there. If there are, then it seems likely that the package is coupled to whatever is required. You need to exercise a little judgment, though. If the required package contains only interfaces, then the coupling is “loose”. Otherwise, it is “tight”. If there are no other required packages at all, then the package has no coupling of any sort; it is fully decoupled from anything outside of it.

However, that’s only if you assume composer.json is not lying. To really discover the coupling of a particular package, you would need to examine its code. Any uses of interfaces defined outside the package indicates loose coupling, uses of classes defined outside the package indicates tight coupling, and no uses of interfaces or classes outside the package indicates full decoupling.

(Note that this discussion is of inter-package coupling. Even if the classes inside a package may still be coupled to each other, the package as a whole may still be decoupled from any other package.)

Having said all this, Taylor is trying out a “contracts” package that exposes the Laravel interfaces independently of the implementations. I think this is a neat idea. It’s the only truly new thing I’ve seen introduced to the PHP community by the Laravel codebase, and I think it is worthy of emulation.

Even so, if the “contracts” include anything besides interfaces, I think coupling to them might be defined as “tight”. I am thinking specifically of the Exception classes included in the “contracts” package. Although it may be fair to think that Exceptions are exempt from coupling rules, perhaps they would be better provided as interfaces to Exceptions, instead of classes proper. I will reserve my judgment on that for a later time.

Read the Reddit discussion about this post here.

Exciting news! After a little over a year in the making, the Aura web and CLI project packages saw their first stable 2.0 releases this weekend. This is a major milestone for Aura, as it means not just the core libraries but also the frameworks built from them are now complete.

Because Aura takes a “libraries first, framework second” approach, the project packages had to wait for the following 2.0 stable releases of these core libraries yesterday:

• Aura.Di (a dependency injection container)
• Aura.Web (web request/response objects, and a response sender)

Once those were stable, it was not much trouble to promote the various kernels and project skeletons to stable as well:

• Aura.Project_Kernel (the kernel files for every Aura project type)
• Aura.Cli_Kernel (the kernel files for CLI projects)
• Aura.Web_Kernel (the kernel files for web projects)
• Aura.Cli_Project (a skeleton CLI project)
• Aura.Web_Project (a skeleton web project)
• Aura.Framework_Project (a skeleton cli+web project)

(Unlike Aura library packages, which have no dependencies because they are completely decoupled from each other, the *_Kernel and *_Project packages do have dependencies, as they are compositions of library and other packages.)

Read more on the Aura blog, including other library releases: First 2.0 Stable Project Releases!.

tl;dr: Instead of inspecting a Domain result to determine how to present it, consider using a Domain Payload Object to wrap the results of Domain interaction and simulataneously indicate the status of the attempted interaction. The Domain already knows what the results mean; let it provide that information explicitly instead of attempting to re-discover it at presentation time.

In Action-Domain-Responder the Action passes input to the Domain layer, which then returns some data for the Action to pass to the Responder. In simple scenarios, it might be enough for the Responder to inspect the data to determine how it should present that data. In more complex scenarios, though, it would make more sense for the Domain to pass back the data in a way that indicates the status of the data. Instead of the Responder inspecting the Domain results, the Domain should tell us what kind of results they are.

For example, let’s look at an example of some older code to update a Blog post. This is MVC-ish code, not ADR code; we’ll refactor along the way.

<?php
class BlogController
{
    // POST /blog/{id}
    public function update($id)
    {
        $blog = $this->model->fetch($id);
        if (! $blog) {
            // 404 Not Found
            // (no blog entry with that ID)
            $this->response->status->set(404);
            $this->view->setData(array('id' => $id));
            $content = $this->view->render('not-found');
            $this->response->body->setContent($content);
            return;
        }

        $data = $this->request->post->get('blog');
        if (! $blog->update($data)) {
            // update failure, but why?
            if (! $blog->isValid()) {
                // 422 Unprocessable Entity
                // (not valid)
                $this->response->status->set(422);
                $this->view->setData(array('blog' => $blog));
                $content = $this->view->render('update');
                $this->response->body->setContent($content);
                return;
            } else {
                // 500 Server Error
                // (i.e., valid data, but update failed for some other reason)
                $this->response->status->set(500);
                return;
            }
        }

        // 200 OK
        // (i.e., the update worked)
        $this->response->status->set(200);
        $this->view->setData(array('blog' => $blog));
        $content = $this->view->render('update');
        $this->response->body->setContent($content);
    }
}
?>

We can see that there is some amount of model work going on here (look for a blog post, attempt to update it if it exists, check for error conditions on the update attempt). There is also some amount of presentation work going on; remember, the view is not the template – the view is the response. So, even though the view templates are separated, the HTTP status codes are also part of the presentation, meaning that there is an insuffcient level of separation of concerns.

In converting this to Action-Domain-Responder, we can pretty easily extract the model work to a Domain, and the presentation work to a Responder, resulting in something like the following. (Note that the Domain layer now adds values to the returned $blog entity to indicate different failure states.)

<?php
class BlogUpdateAction
{
    // POST /blog/{id}
    public function __invoke($id)
    {
        $data = $this->request->post->get('blog');
        $blog = $this->domain->update($id, $data);
        $this->responder->setData('id' => $id, 'blog' => $blog);
        $this->responder->__invoke();
    }
}

class BlogUpdateResponder
{
    public function __invoke()
    {
        if (! $this->data->blog) {
            // 404 Not Found
            // (no blog entry with that ID)
            $this->response->setStatus(404);
            $this->view->setData($this->data);
            $content = $this->view->render('not-found');
            $this->response->body->setContent($content);
            return;
        }

        if ($this->data->blog->updateFailed()) {
            // 500 Server Error
            // (i.e., valid data, but update failed for some other reason)
            $this->response->status->set(500);
            return;
        }

        if (! $this->data->blog->isValid()) {
            // 422 Unprocessable Entity
            // (invalid data submitted)
            $this->response->setStatus(422);
            $this->view->setData($this->data);
            $content = $this->view->render('update');
            $this->response->body->setContent($content);
            return;
        }

        // 200 OK
        // (i.e., the update worked)
        $this->view->setData($this->data);
        $content = $this->view->render('update');
        $this->response->body->setContent($content);
    }
}
?>

But at this point we’re still inspecting the Domain result to see how we should present it. This strikes me as a lot of work to determine something the Domain already knows.

Instead of re-discovering the Domain status in the Responder, we should let the Domain tell us not only the data, but also what to think about that data. The Domain should give us an indication as to what it tried to do, and whether it succeeded or not. Then we can completely skip the inspection of the Domain results and present those results without lots of additional work.

The key to doing this is something called a Domain Payload Object. (Initially I called this a “Domain Result” but my recent reading of Vernon’s Implementing Domain Driven Design revealed the term to me. I love finding the right word for a concept!)

With a Domain Payload, we wrap the Domain results in an object that carries those results for us. We can then extend the semantics of the Domain Payload to tell us what kind of payload it carries. Something as simple as the class name of the Domain Payload can give us that information.

In the ADR example code we will find a series of Domain Payload objects. While these map closely to HTTP response codes for simplicity’s sake, other Domains are very likely to have different kinds of payload statuses. The point is that each Payload object explicitly tells us what the results indicate: entity not found, invalid data in the entity, database error, successful update, and so on.

The BlogUpdateAction remains straightforward. However, the example BlogService‘s update() method now does all the update work, and it wraps all returned results in a Domain Payload that indicates the result status.

Finally, the BlogUpdateResponder, which itself extends an AbstractResponder, can match a Domain Payload class name to a method that presents the payload results.

Voila: no more inspection of the results to figure out presentation. We let the Domain tell us what it tried to do and whether it worked or not (and what the cause of the failure was, if any). At the presentation layer, our Responder can honor (or ignore) that information at its convenience.

Read the Reddit discussion about this post here.

Hollywood lies to you. You cannot have sex with multiple men before marriage and walk away emotionally and physically unscathed. There will be no handsome millionaire willing to marry you when you’re 33 and ready to settle down. Once you’re married, adultery is no light, breezy thing. You probably won’t live in that huge home with a pool and a maid to do the cleaning. Your “high-powered” career will mostly likely consist of tedious paperwork in a claustrophobic office cubicle as you daily work through messy office politics and cope with a few difficult colleagues, while worrying about all those unfinished tasks at home. All too often, especially if you made poor choices about what to study in college, you will not get your dream career. You might actually end up being the maid or the nanny for another woman, doing the same housework/childcare in a stranger’s home that feminists always told you was sneer-worthy work to do in your own home. Your debt load will scare you. Your loneliness could shatter you. Men will come and go as they use you for their sexual pleasure and you will pretend to feel “empowered” by letting them do so. Those of you who do marry will have to work hard at suppressing some depression-causing discontent in your late 30s when you look at your non-movie-star husband, the average home that’s as nice and as big as it’ll ever get, the kids who are just as special and wonderful as every one of their classmates, the neighbors who have more holidays and nicer vehicles than your family, and the sheer ordinary-ness of your life compared to the lives of the rich and famous.

Some women break. When a single woman breaks, she chiefly damages herself. When a married-with-children woman breaks, she damages many other lives as she runs off in search of the fantasy world of “perfect-happiness-with-a-gorgeous-sensitive-rich-man” that Hollywood fed to her.

As I said, there are many reasons why all too many Western women are unhappy. Hollywood is one of them.

via One Reason Western Women are Unhappy | Return of Queens.

In one experiment, Wiseman asked people to self identify themselves as lucky or unlucky. Then he gave his test subjects a newspaper. “Count the number of photographs inside”, he told them.

There were 43 photographs.

On average, the unlucky people took 2 minutes to count them all. The lucky people? Seconds.

The lucky people noticed the giant message that took up half the second page of the newspaper. It said, “Stop counting – There are 43 photographs in this newspaper.”

The unlucky people missed it. They also missed the equally giant message half way through the newspaper, “Stop counting, tell the experimenter you have seen this and win $250.”

The “lucky” people weren’t lucky. They were just more observant.

via Why are some people so much luckier than others?.

A summary of Vox Popoli: Mailvox: the distribution of atheist intelligence:

- On average, atheist IQ is a little higher than theist IQ. Of course, averages are misleading, because ...

- There are more high-IQ theists than high-IQ atheists.

- The majority of atheists have sub-100 IQs.

- "The two most common types of atheists are the High Church atheists with 128+ IQs and Low Church atheists with 65-72 IQs. The Low Church atheists actually outnumber the High Church atheists, 22.9 to 17.2 percent."

- "There are 11.4x more 128+ IQ theists who either 'know God exists' or 'believe God exists despite having the occasional doubt' than there are 128+ IQ atheists who 'don't believe God exists.'"

See the article for an interesting set of graphs.

Part of me wonders if this accounts for the "I Love Science!" crowd, despite not actually know what science *is*, as well.

FWIW, I was raised a Methodist Christian, so I have a warm place in my heart for religion. In adulthood I became an agnostic, not an atheist, so I have no particular dog in that fight. I have not taken a formal IQ test so I do not know where I fall on that scale. I like science as a methodology, which is why I am perturbed by messages purporting to be "scientific" when they are not.

Novice researchers often enter behavioral psychology convinced of the blank slate thesis. They believe that little boys and girls are born tabula rasa. Parents, teachers, and society then proceed to mold children’s interests, talents, and temperaments towards the dominant gender stereotypes.

Tenured faculty members have a word for blank slate proponents: “childless.”

In other words, men and women (on the whole and in the main) are physically, intellectually, and emotionally different. Thus, you don't need "the prejudice of sexism" to explain disparities. All you need is differing internal motivations, preferences, and interests. Yes, at the tail ends of the distributions you may find overlap, but if the significant majority show similarities to the rest of their sex, then even a small set of sex-based differences can lead to widely divergent outcomes between sexes.

But that gives Social Justice Commissars a lot less to work with, so of course it must be a result only of sexism. (/me rolls eyes)

via An 'Ether Of Sexism' Doesn't Explain Gender Disparities In Science And Tech.

If you are a fan of "Alien" you really should watch "It! The Terror From Beyond Space". The plot elements are remarkably similar.

FP: You make the shrewd observation of how political correctness engenders evil because of “the violence that it does to people’s souls by forcing them to say or imply what they do not believe, but must not question.” Can you talk about this a bit?

Dalrymple: Political correctness is communist propaganda writ small. In my study of communist societies, I came to the conclusion that the purpose of communist propaganda was not to persuade or convince, nor to inform, but to humiliate; and therefore, the less it corresponded to reality the better. When people are forced to remain silent when they are being told the most obvious lies, or even worse when they are forced to repeat the lies themselves, they lose once and for all their sense of probity. To assent to obvious lies is to co-operate with evil, and in some small way to become evil oneself. One's standing to resist anything is thus eroded, and even destroyed. A society of emasculated liars is easy to control. I think if you examine political correctness, it has the same effect and is intended to.

Emphasis mine. Via FrontPage Magazine - Our Culture, What’s Left Of It.

I had a patient, let’s call him ‘Henry’, who came to hospital after being picked up for police for beating up his fifth wife.

“And why, exactly, were you beating your wife this time?” I asked.

“She was yelling at me, because I was cheating on her with one of my exes.”

“With your ex-wife? One of the ones you beat up?”

“Yeah.”

“So you beat up your wife, she left you, you married someone else, and then she came back and had an affair on the side with you?” I asked him.

“Yeah,” said Henry.

* * *

When I was younger – and I mean from teeanger hood all the way until about three years ago – I was a nice guy. In fact, I’m still a nice guy at heart, I just happen to mysteriously have picked up girlfriends. And I said the same thing as every other nice guy, which is “I am a nice guy, how come girls don’t like me?”

There seems to be some confusion about this, so let me explain what it means, to everyone, for all time.

It does not mean “I am nice in some important cosmic sense, therefore I am entitled to sex with whomever I want.”

It means: “I am a nicer guy than Henry.”

I didn’t think I deserved to have the prettiest girl in school prostrate herself at my feet. But I did think I deserved to not be doing worse than Henry.

(Edited for succinctness.)

Bad news, nice guys: what women (especially feminists) *say* they want, is very different from what they *actually* respond to. Don't listen to their words; instead, observe their actions, then organize your life accordingly.

Via Radicalizing the Romanceless | Slate Star Codex.