Ok, so we’re basically not arguing. Distinguishing between event types will reduce the likelihood of misuse even if it can’t really be enforced by PHP. Is that a fair summary?

Click does allow the caller to suppress/capture responder output, so the ECHO example is not a problem but your general point stands. Click has thus far been used by a small core of expert programmers, so the issue of event type abuse has not surfaced. I see how it could though. After writing this post I got to thinking that WP’s immutable-positive approach to life probably leads to more stable plugins. It reduces the likelihood that something will be misused or inadvertently modified.

Regarding the impetus for filters/actions, I want a world where someone was sitting around a long time ago trying to figure out how to hook into some blog post output and said “hey, I know, I need to run the post output through some FILTERS!” And then, someone wanted to shoot an email out based on a trigger and didn’t like using a filter for it so they said “hey, I know, we need some ACTIONS!” And the rest is history. Something about it just feels bloggy to me and I want it to be true. I want it to be evidence of an organic evolution from blog engine to CMS.

Maybe Brad is a thief. What I object to is the chickenshit way the guy goes about smearing Brad’s name. Open a real discussion if you have something to say. Otherwise you’re just introducing FUD which is a form of evil. You are choosing to be evil.

So what we have here is:

Client – Definitely Evil
Gunn – Maybe Evil

The difference is that actions are specific defined places in the code where you can run some code of your own, doing whatever it is that you want to do. Filters, on the other hand, are designed to change existing structures in the code.

The distinction is that actions are placed at points where it would make sense to do something outside the normal flow of things, while filters are intended to only modify pre-existing things and not to modify other things or cause output or the like.

This is not a trivial distinction, actually. Placement of these this in the normal flow of WordPress code is designed around this, more or less. Actions rarely receive any arguments, they’re simply defined points in the running code where one might want to hook in a function to do something. Filters tend to be mostly used in return statements where the value of a function being returned is first passed through a filter to potentially be modified.

Your “event” system doesn’t account for this. What if one were to take an event and instead of returning something, they produced output to the main output stream. In PHP, this would be basically doing “echo ‘HELLO’;” or similar? If you did it in the wrong place, this could break the output of the page. With the distinction of actions and filters, it’s fairly obvious that a filter should *never* do this, while an action hook *might* be the right place to produce some kind of output.

Most actions (not all) typically run one time only in the page processing. There’s only ever one “init” or “plugins_loaded” call, for example. Filters can be used by anybody to filter whatever, and might run more than once.

That sort of distinction does matter, and it’s not an accident.

svn:ignore ?

I disagree with Joey in one huge way: doing things now for a possible payoff “when and if” (as he says) is a really, really bad idea. We disagree on timing, emphasis, and the link between scalability and your success.

Almost every developer you talk to is going to have Joey’s attitude: plan early, architect the shit out of it, build for scalability from day 1, and beat the scalability drum loudly as you parade around spewing theoretical knowledge.

You can go that way. There are many developers who will sell that distraction and burn your budget. But intuitively, you know his viewpoint is wrong. You know from your own life experience that the best laid plans go to waste. The allure of the silver bullet is the only thing that makes Joey’s attitude seem so compelling. We want to believe. It would be so dang convenient and enabling if we could find a way to make big plans that work.

What I am about – and what my philosophy is about – is to know and understand the theory while recognizing that reality throws theory out the window. It doesn’t sound very sexy until you’ve gotten burned by the advice of a few Joeys. After you experience bad advice first hand, you become a believer in Benkido.

Scalability is a form of optimization. You can’t optimize for a general case. You need a concrete situation to study and solve. What’s funny is nearly every programmer will agree that optimizing too early (i.e., before you have a specific problem) is a bad idea. But here’s Joey, seemingly knowledgeable, telling you to do exactly that. And he’s got a lot of company.

Consider this: more projects fail from lack of business analysis than all other reasons combined. I have witnessed and participated in the design of scalable solutions that never ended up launching because they missed the market window, or missed a critical feature, or just plain ran out of money before they could complete the minimum feature set. Everyone focused on scalability and perfect design. We nailed it. And we lost, because our attention and resources were in the wrong place.

Here’s the pragmatic question for you: if scalability doesn’t make you a winner, what does? The answer, of course, is pragmatism. If you focus on the pragmatic choice at each step, you will maximize your chances of success.

For some reason, people really don’t like the idea of not planning ahead very far. I know I sure didn’t like it at first either. It was uncomfortable. Counter-intuitive. I wanted to plan. I needed to plan. But after I let the process work, I saw that pragmatism was leading to ingenious solutions I never would have imagined. Pragmatism is smarter than we are.

My philosophy says that scalability is a by-product of short development iterations and staying tuned in to customer demands. You can’t do that if you spend your whole budget, alone in the woodshed, building a scalable solution to a problem that nobody actually has. The real world is very subtle. Little differences between what you think will work and what actually works carry huge design implications. If you stay focused on what people need – real people who have a problem worth paying money to solve right now, today – your system will evolve into something more beautiful, more scalable, and wildly different than anything you had imagined. Just let evolution take its course. Your software will adapt in very clever ways.

Sorry Joey. I’ve seen it happen. I’ve made it happen. I know what I’m talking about.