Laravel just jumped the shark ... annotations

I think annotation is fine and it should remain optional to laravel.

@tag I totally agree.

I'm really disappointed to see these ugly and useless annotations in the main source code :'(

I think the answer to your issues with annotations is don't not use them, you can still populate the routes.php file.

They certainly aren't for everybody, I had a tinker with them last night and found them most efficient and I can see they will save me a lot of time particularly for larger projects so I like them.

Let's not forget that they are doc blocks, and not reserved solely for comments.

You still have choices with Laravel and the ability to construct an app as you see fit, this is the beauty of it and I think will remain in that mode for the foreseeable future.

I can't comment on the middleware as I've not looked at it in any great depth.

I don't get it - why complain about a feature you don't have to use?

@ajschmaltz as mentioned by @tag these abominations are starting to spread in the source code.

@pmall and @tag... I like you am not a fan or sold on annotations.... However, just because I don't like them, doesn't mean they are an abomination. It just means that the are a feature we don't care for but someone else finds useful.

@token, "Annotations also suck because comments should never affect the flow of code. Ever." well, comments don't ever affect the flow of code. DocBlocks can though. There is a pretty big difference between DocBlocks and comments.

I think part of the problem is people have for years been interchangeably using and mixing comments and DocBlocks, you see people throwing around /** like it's nothing :)

Also @tag, Taylor has mentioned that filter support isn't going anywhere as he doesn't want to break people's current filter implementations, but hopes people will see the benefit and usage of the new Middleware.

It really boils down to preference, and either side calling either opinion an abomination just shows very closed-minded attitudes.

Use them if you want, don't use them if you don't want to...

The beauty of "choice" is that's what drives and pushes languages, applications and technologies to the edge of what we never thought was possible.

My personal opinion is that "this is the right way or this is the wrong way because that's not how I do it" is the biggest hindrance to growth and change.

Just my two cents :) Happy coding!

@dberry saying that it's only a matter of opinion is also closing the debate.

I just think that :

• They are useless (nobody showed any true benefit of this).

• They are complicated (route scanning, auto route scanning, generating another file containing route definitions).

• I can't see the point of adding such a controversial feature that a lot of developers like @tag and me loath. Nobody cared about this nor even through about it and was happy with its routes.php file.

• It will confuse everyone (especially newbies) with two completely different approach for something as trivial as routing. I think options and choice are suitable only for complex tasks. For trivial tasks like routing less options is more. What if my coworkers wants to use annotations and I don't ? And I can already imagine new shiny packages that completely mess with the routing of our apps because they use annotations and we don't.

• All the problems related to code in comments.

• A lot of newcomers will be turned off by a framework that use... code in comments.

• They are imposed to us (as they are used in laravel base code as mentioned above).

I think this functionality would be perfectly fine in a complete separate package. Why this option isn't investigated ? Form & HTML builders are now a separate package but annotations are delivered straight to your face.

And don't get me wrong I use laravel daily at work and I can't describe how much I enjoy L5. At least as much as I loath annotations :)

IMHO We should insist on the usage of $router->resource(). It's clean and easy, suitable for almost all situation, and would help the newbies to structure their app better.

Question is, was this Taylor's idea or was it someone trying to contributing ideas to the framework...

Correct me if I'm wrong, but DocBlocks are still comments. PHP does not parse DocBlocks at run-time, correct? It was my understanding that DocBlocks were created to give developers a "standard" for documenting their code, along with giving hints to IDE and making them more powerful.

At the end of the day, DocBlocks are still comments and require some external tool or resource to parse them and figure out what you're trying to do (if you have executable code in them).

I may have my head in the sand, but could someone explain to me the huge benefit that annotations provide? This certainly seems to be quite a controversial topic within the community right now.

Hopefully those guys who took a giant shit on Facades won't be too opinionated about this. ;)

Also, regardless of which side of the fence that you're on [with annotations or ANY new feature] in Laravel, I think we can all agree that we're on the same team. Healthy disagreements within the community are a good thing! It helps the framework/community grow and mature.

Taylor isn't perfect. He isn't always going to get everything right (albeit he's done a pretty damn good job). And WE, the community, aren't always going to see the immediate benefit of a decision that Taylor makes.

@JoshWilley this has been thrown around several times in the past few days, but is worth a listen http://laravel-news.com/2014/08/laracon-slides-php-annotations-exist/

DocBlocks are comments, but a little more powerful than comments and since the mid 2000's comments (/* //) are ignored by opcode cache whereas docblocks (/**) are cached by opcode. So there are some differences in standard comments versus docblocks.

@pmall, I agree with 90% of your points above. I don't loath annotations, but I'm also not opposed to people using them.

I don't think it is very confusing at all. If people have a trouble understanding that, then they have bigger issues. I think catering to every beginner developer out there is not a good choice or option. Some people just won't get it.

I do agree that route scanning seems a little less robust than I'd like to see, but also remember, we're in pre-alpha basically so that could change. It's also extremely easy to extend and create your own Route Scanners. I threw together something while messing with it in about 30 minutes where I could use a config file for directories or in packages use a method ->addDirectory($directory). Again, I like the routes.php file, but still wanted to try it out.

For every person that loathes annotations, there is someone who doesn't and is ready to embrace them.

Symfony, Doctrine, C#, java, ruby, oracle, scala, python all have annotation implementations. So this really isn't something that is unique or unheard of in the programming world.

Annotations aren't new to the PHP world, there have been implementations since 2005 when 5.1 was released and the docblock parser was introduced.

I just don't see it as being as big of a deal as people are making it out to be on either side of the fence.

It's just another option. He's not forcing you to use it in the code that you develop.

Just my two cents :)

They are useless (nobody showed any true benefit of this).

We've shown a few. At the very least, it makes for a significantly faster workflow.

They are complicated (route scanning, auto route scanning, generating another file containing route definitions).

Route scanning is automatic now. You literally don't have to do anything now to make it work.

I can't see the point of adding such a controversial feature...

It's not that controversial. Lots of frameworks use route annotations. In fact, the Symfony leads recommend route annotations as a best practice (over a PHP or YAML file).

It will confuse everyone (especially newbies) with two completely different approach for something as trivial as routing.

Well, that's why I suggested that we don't include the route.php file, by default. That way, if you still want that approach, you manually include it..and you're done.

All the problems related to code in comments.

Bleh. They aren't comments. This has been said many times now. PHP's Reflection API gives us a nice and clean way to read that metadata.

IMHO We should insist on the usage of $router->resource()

Why is that so much better than...

/**
 * @Resource("users")
 */
class User {}

I know this has been said a couple of times... but as far as I'm aware, the use of Annotations isn't compulsory. If you don't like the feature, don't use it... continue with the method you do like.

I, personally, prefer this idea of annotations, but I guess it's subjective and down to personal preference.

Yeah, I really think this has become a bigger issue than it really should be.

I wish I could explain things as concisely as Jeffery.

The only thing he said I differ on is on the confusing everyone. Neither and even both together is not a difficult concept to grasp and really shouldn't be that confusing. I'm pretty confident that between Jeffery & Taylor, it can be explained in a nice little paragraph and a short little video.

@tag - you don't understand the new features that you are complaining about, so maybe you should actually research them first.

In a middleware you CAN do $request->route(), $request->user(), $request->session(), etc.

Good grief people whining and moaning about stuff they don't even understand is getting old.

"@JeffreyWay Why is that so much better than..."

In which way is this a faster workflow ?

In fact, the Symfony leads recommend route annotations as a best practice (over a PHP or YAML file).

This is my fear regarding them - that the documentation and certain architectural patterns will be designed with annotations in mind (that is, what could have been implemented easily and cleanly in PHP, now has a cumbersome implementation because "you can always just use annotations").

Laravel is made of kick-assery explicitly because its setup and API is clean, straightforward, and pure PHP. There are some instances string-based pseudo-language like how validation rules work:

'email' => 'unique|users,email_address'

or dot notation here and there, but nowhere near as bad as the nasty string-based pseudo-language of Symfony expressions and random configuration values:

http://symfony.com/doc/current/book/service_container.html#book-services-expressions

'%newsletter_manager.class%' @=service('mailer_configuration').getMailerMethod()

because you know, that's totally clear...

Well DocBlock annotations are the same thing: they are their own string-based pseudo language that doesn't get properly completed or checked by your IDE or editor.

@Middleware("guest", except={"logout"})

Why the brackets? Why not:

@Middleware("guest", except="logout|something|else")

What other random language elements exist in the DocBlock parsing? I don't know because I know PHP, not some arbitrary userland pseudo-language bolted on to PHP all because reflection is so easy to abuse...

It's one thing if this annotations remain 100% optional, but quite another if they start dominating the documentation or even making non-annotated code more cumbersome to write.

I just want to reiterate that annotations is arbitrary userland syntax bolted onto official PHP syntax. This is problematic for the PHP community as it now means that a large number of collaborative projects have userland syntax affecting execution flow - syntax for which there is no official documentation to reference, only third party documentation.

What's more is now code execution is that much more fragile and susceptible to changes in the reflection API between PHP versions. There's also zero guarantee of backwards compatibility, or upgrade stability because Doctrine Annotations is maintained differently than PHP is. While PHP is relatively stable because it has to be, Doctrine Annotations (or whatever docblock parser is being used) could change wildly, making code-bases either more volatile, or harder to upgrade. I know this all sounds like FUD, but stability/fragility/learnability are real concerns for real teams of varying skill level building real software.

I'm all for annotations if they were implemented officially in PHP, but not when it's some arbitrary userland abuse of the reflection API...

@pmall Less typing, less file switching, better readability.

@JeffreyWay very subjective. Ok I'm done with complaining.

@dberry - But should it need to be explained? Remember, we're talking about routing here, I think...

This is the fundamental entry point for everyone into a framework. When you first get into a framework, you want to setup a route and spit something out in a browser.

With Laravel, you don't have to think about how to accomplish that. There is a routes.php file setup by default with an example route. Couldn't be easier.

I completely agree that Laravel should not cater to every new developer's needs and interests, but I think that even the most senior developers will agree, routes are not something that they want to worry about.

Yes, you have a choice. But we're all human, and when you go home at night, you may have that little nagging voice that says... "You're still using the old routes.php file, you suck. Go check out those annotations that everyone is raving about. You're going to be left behind."

We all strive to be cutting-edge. That's why we're software developers. We are literally the forefront of society right now, and if you're feeling left behind in this industry, it really can't be taken lightly.

That last point may be a bit exaggerated, but you get my point.

@tag - I agree. Laravel's explicit nature is what makes the framework. I did a bunch of research on ORMs a while back and it took me 5 seconds to decide between Eloquent and Doctrine. The reasoning? Annotations.

For all I know, Doctrine may have an alternative to annotations, but I didn't bother to look because the documentation and tutorials all pushed annotations. I was done with it immediately.

Obviously this comes down to personal preference, but personal preference is what determines who uses your product.

@JoshWilley, that was exactly my decision flow as well.

Eloquent: clear, straightforward, scannable documentation. Can learn 80% of what you need in no time.

Doctrine: wtf-is-going-on-im-too-busy-for-this-shit documentation...

So much doom and gloom...

@JoshWilley, yes it should be explained. Why would it not be something that needs to be explained?

I also do not get that feeling when I go home. I may get the feeling of "this is something that I would like to look at a little more and see if I'm missing something or is this something I can use to improve what I'm doing" I never do something just because it's cutting-edge, that's not a good enough reason.

@Tag, aren't frameworks in general opinion-based "userland" tools?

This is worse than the OS X vs Windows vs Linux thing ;)

@JeffreyWay

No doom and gloom, I just don't want to see Laravel become as clumsy and awkward to learn as Symfony is. Laravel's strength is that it's just as flexible and powerful as Symfony, but significantly easier to learn, and IMO significantly easier to work with.

@deberry

In terms of their APIs, yes, but their APIs are still rooted in PHP as a language. Annotations are another language entirely, with their own syntax and parsing rules. Imagine an application where some of it is Ruby mixed directly in with PHP, whereby PHP was executing string-based Ruby throughout the application. That would be ridiculous.

Again, annotations would be fine if there was an actual official PHP implementation of them.

@tag, ah you mean like blade, twig, etc... Those should all be dropped too then since you have to learn their syntax and aren't part of the PHP core.

Sigh!

This debate has gone on far too long here and else where.

Regardless of everything that has been said, they are here now (they were actually the original routing method for L1 I think, but were later removed), use them or don't use them, love them or hate them, stop using Laravel if it has offended you that much, end of the day it won't change a thing.

As far as making Laravel clumsy or awkard to learn, I'm sure @JeffreyWay will have something to say about that, not too mention all the other bloggers that are covering L5 :)

I, for one, am incredibly happy with all the changes that have been made to Laravel, and since adopting Laravel from 4.0 my own skill level and understanding of coding in general has increased exponentially and for that I am grateful to @TaylorOtwell and the community.

Hell, if I was to repaint the sistine chapel ceiling, their faces would be up there :)

Hell, if I was to repaint the sistine chapel ceiling, their faces would be up there :)

Someone with better photoshop skills than me, please make this a reality! I would love it as my desktop wallpaper, maybe give the guy on the left some pants though.

My 2 cents - I use annotations (mostly in C - attributes) and see the use cases, but would make the case that developers who build developer applications like annotations more than developers who build customer applications as it is more of a black box "this will help you" feature. However, black box features almost always create more problems than they are worth. Think about the debugging conversation between developers using a framework (different when just simple single app). Again, not MIT graduates with 10 years dev experience, but the average Joe.

"it seems like it is a route issue. where should I look?"

"well take a look at the routes.php file, if not go look in the controller to see if there is problem with the routing annotation, if not then go look in routes.scanned.php, if not then go look through each file that has anything to do with the project to see if someone screwed something up in an annotation somewhere"

If I'm building an application for me then I would absoluetly use annotations, but if I'm building it for someone or part of a team I probably won't unless I'm convinced that the team has the skills to debug it.

One source of the truth is always better when things go wrong. Not when things go well. AngularJS does a lot of black box approach and I hate writing Angular code, not because it is bad, in fact brilliant, but because it was designed by a bunch of very smart MIT people at Google who started each feature with "you know what would be cool" and the world needs to be SPA.

Simplicity is why I recommend ReactJS above Angular to customers even though ReactJS doesn't have half the features of AJS. Because I know that when I hand it across to a customer that they will get it, it is simple and therefore, less support (costs) on my end, happier customers.