Your controller is still tightly-coupled to Laravel's Form Requests, plus the View, Redirect, and Response facades or their equivalent helper functions.

coupled only to Illuminate/Contracts right?

When you use any framework, you at some point have to make some sort of coupled commitment to that framework. You can't just completely decouple everything, the only way to be completely decoupled from a framework is to not use any framework. I've never understood the "being too tied to a framework argument". That's the sacrifice you make when you don't write the code yourself and use a framework. You see so many people going out of their way to "decouple" and end up writing completely redundant code and losing some of the major benefits that the framework has to offer.

As for annotations, I'm not sold yet. Could be a good thing, could be a bad thing. I don't think it really matters as long as both options are out there and you're free to choose. The only thing that I can see happening is someone using it, you not noticing it up in the comments and something breaking, or some of these IDEs like to change around comments, that could be an issue.

I'm a big Laravel fan, have been since early 3.x. But annotations seems to be against the whole spirit of Laravel, for what I understand it to be.

I may not be able to articulate it as well as others here, but did want to put my voice out there. I think @rspahni has some very good comments as well.

I have minimal experience with annotations, but it feels a bit like reinventing the wheel with a new tool... and if we ever want to expand on it, we have to continue to expand on the new tool. Or if I want to do something a little unconventional, I'm tied to this new wheel... or to invent my own new, new wheel.

I don't get to work with Laravel everyday (yet!), but that's my feelings on it. We're actually in the planning phases at my full-time job to migrate completely to Laravel, so I'm eagerly awaiting to 5.0 release. :)

@dberry, I completely agree about frameworks. I use a framework like Laravel because it provides a lot of really useful features. I don't care that I'm tied to it, because it makes my life a lot easier. Having to spend time manually implementing a lot of the boilerplate code to ensure I don't lock myself into a frameworks awesome functionality seems pointless. A framework is an opinionated body of work designed to make things easy, if you want to follow their opinions and design choices.

If you're building an app which may need to swap frameworks in a few months/years, then don't use a third-party framework. Implement your own custom framework, and pick and chose the specific components you need to make it work. That way, you can easily swap out components, but the application keeps running as per usual.

Trying to have it both ways ends up with a mess like ZF2. ZF1 was fantastic, it got out of your way and let you get work done. ZF2 was built with such an abstracted, best-practice, perfect-code-design mentality, that even simple things take far too much effort with it. Laravel 4 got out of your way and just worked to make your life easy. Laravel 5 seems to be losing some of the simplicity - but since it's not out yet, I am hoping that Taylor makes it so you can either use L5 as-is for simplicity, or make the changes you need to abstract things.

As for Annotations. I hate the idea. They are custom markup that isn't checked by any code validators, and since they are in comments, they are too easy to miss. At the very least, couldn't that config go into a static array property - would be just as readable, probably more usable, but also php linters, etc, would actually verify them. I prefer keeping routes and controllers separate, so you can change your routes without having to modify controllers. The controller doesn't care how it's called, or what the URL looks like, just that it has been called. Likewise a route doesn't care what happens when it's called, just how it fits with the rest of the application route schema.

Fingers crossed Taylor will keep non-annotation-based route config in L5.

If the comments are now part of the code, where do I put my comments? Not trying to be cute...

Also, the framework has to find the annotations, parse them, then do something? Searching through the annotations is not a native PHP feature. Is this feature stemming from Symfony? Or, is his feature just Laravel?

Conventions :

/**
 * This is my awesome comment
 * What do you think ?
 *
 * @Annotation1
 * @Annotation2
 *
 */

Some tips by Matt Stauffer:

http://mattstauffer.co/blog/laravel-5.0-route-annotations

Does the ordering of methods determine the ordering in the routes.scanned file? If so, it seems very odd to need to place one method before simply another to satisfy a routing issue.

I'll leave this here:

https://r.je/php-annotations-are-an-abomination.html

@tommymarshall To be fair, we already have to do this in the routes.php file to determine the order in which routes are checked, ie. always make sure your catch-all route is at the bottom.

@demians - Much of that does not apply.

I don't have a strong opinion about whether annotations are right or wrong. But it certainly does feel very un-Laravel-y.

@JeffreyWay Because the framework will generate concrete stuff out of annotations? I'd rather not use them at all, logic doesn't belong in comment blocks.

@demians - Tell me how your life will be worse, if you have the option of registering routes quicker?

@thepsion5 That's true, but that's because routing order is important. To my original point, reordering controller methods -- ordering which has never mattered before -- to satisfy a routing issue doesn't make sense. Reordering defined routes to solve a routing issue makes sense.

FWIW: I don't have a problem this being in the framework. I've never been convinced Annotations are a good idea but perhaps this conversation is the start of it! :)

@JeffreyWay I have between 10 an 15 teams of devs of every seniority level you can think of, and we are switching to Laravel. It's not only about the functionality Laravel provides, it's about architectural decisions that can destroy our projects, and the ability to understand this decisions in every level, in every team.

A poor architectural proposal from the framework that our architects chose to use may influence other decisions as well, and that propagates fast.

@JeffreyWay how/why is this supposed to be quicker than the proven $this->beforeFilter(), with an additional command to be run and without editor support for code completion? The more I see of this, the less I get it. I'm not backward, just not seeing the point at all.

@demians - Sure, but that makes the assumption that this is a poor architectural decision. Much of the annotation debates are dated. We should instead be asking about the benefits, rather than immediately reaching for the "reject" button.

@JeffreyWay I love annotations. I have used them in previous projects in .NET and Java.

PHP doesn't have Annotations. We parse comment blocks to mimic a functionality missing from the language, and that's dangerous. It was dangerous before, it's still dangerous now.

The benefits might justify the danger. What are the benefits?

As I said on lesson "Observe This, Fool", it is ok to have it as option, but if i need to run route:scan every time I add new route, it does not save me any time, and using some automation tool like gulp for these kind of things is just pointless.

For me, being able to checkout the routes.php file and get a good view of what's going on is always handy. Sure, you can call an artisan command to see the routes too, but that's not as efficient when you're working in a text editor (imo).

Although I do like this, I think it could make it harder for outsiders to know what's going on, as to me the routes are the first thing I'd take a look at.

@JeffreyWay plus, we both know that coding is not how fast you can type something. Having Annotations in a Controller won't make an XL task M. It won't have any effect on productivity. It's syntax sugar, with the (IMHO) huge downside of being comment block parsing.

I would prefer the EventServiceProvider or gulp options, because if you forget run event:scan some listeners couldn't be run.

After reading the thread a few thoughts of my own haven't been raised by anyone else.

1. If you're documenting your routes with something like Swagger UI there is going to be some similarity in you @Resource and @SWG\Resource declarations (example http://zircote.com/swagger-php/annotations.html#resource), this could be confusing and lead to confusion and a mixture of comments and logic in the docblock. My docblocks are just that: documentation blocks.
2. @JeffreyWay - I see your point on using gulp to do php artisan route:scan – however… I use linting in Sublime Text so that when I save a file I know that it's valid PHP and that gulp will run without error. Gulp should only be reporting test failures (in my workflow anyway). If there is an error in my annotation, how useful will the debugging message be from routes:scan? It feels like an unnecessary extra step.
3. Anyone checking out the code from a repository needs to run artisan route:scan to get a working application - currently checking out is all that's required (in my cases, at least!). (Minor point, but the less friction for developers the better, right?)

On the flip side: I can see that anyone with 500+ routes or complex routing/logic requirements might want this, however it's not for me!

I like idea of Annotations and POPO controllers. Take in mind that Doctrine2 (ORM) is powerful because entities are POPOs and mapping could be annotations (popular or at least give you an idea of what is going on with your entities), yaml, php array.

So it is easier to look at your entities and if interested think on what is going, but is hard to look at controller figure out how it is mapped ?

Note: It will be a lot better if that annotations are namespaced .. so if i want Routing => ue Illuminate\Routing\Annotations as Route and then @Route\Get If it is event ..Illuminate\Events\Annotations as E` => @E\Hears

We use ODM and ORM in our laravel 4.2 project and it is a lot clear when something starts with @ODM or @ORM. Moreover in case of Doctrine you can persist object in both via annotations because even if declaration is the same .. it is namespaced @ODM\Id !== @ORM\Id ; What if someone @Get annotation for some some reason and everything mess up because of Controllers, events etc

In fact an array with definition where are controllers / listeners will follow Doctrine approach of using annotations and saves some writing in console (--namespace --path etc) (probably performance too ; intead of scanning whole project. It is not magical).

So instead of thinking how everything should be magical and easier for newcomers lets implement things which are working for big applications too: annotations namespace, scan folders, etc

I think my main opposition to annotation based routing is just that now you need to make a change in a controller to update a route.

Having to open and change a controller to make a change to a URI sounds like a backwards dependency to me. If I have a /register route and decide I want to change it to /sign-up, it shouldn't matter to the controller.

I know Taylor says he likes the idea of configuration living with the thing it's configuring but I don't think I agree.

Imagine if instead of choosing a Queue driver in a config file, we had to find the driver we wanted to use and stick an annotation on top?

/**
 * @UseThisOne!
 */
class RedisQueue extends Queue implements QueueInterface {
    // ...
}

It really feels like a step backwards to me. I hope it's not encouraged as the primary way to register routes.

It sounds like there's still a lot more to the story, so I'll wait and see what 5 looks like when it lands. I've always thought Taylor has made great decisions and had the right priorities when designing features for Laravel, so I think it's fair to keep trusting him for now :)

To me, "POPO with annotations" is a contradiction in terms. I.e. plain old php objects do not feature logic in docblocks, do they, at least not in the plain old php books I've read. And this seems to be causing a major dependency on Laravel (same "POPO" incl. annotations will lose its magic in Fuel or ZF) while Illuminate\Routing\Controller disappeared on the premise that controllers must not be coupled to the framework. Semantics aside though - I'm still waiting to hear what/where the real-life business case is, i.e. incremental benefit over combined proven routing options up until 4.2. @adamwathan, according to laravel/laravel repo on GitHub https://github.com/laravel/laravel/tree/develop, this will in fact be encouraged as the primary way to register routes.

90 posts and nobody is pointing out a true benefit of annotations.

And I may be a strange developer but I don't like the "there is many ways to do things" approach. Its confusing. I prefer that there is one great opinionated way to do things. No overhead.