Hacker News new | ask | show | jobs
by blowski 5000 days ago
What's in the annotation is configuration, not application logic. As such there's no real difference between putting configuration into YML, XML and annotation comments.

In response to your 4 specific criticisms: 1. (DX regressions) - in theory yes, in practice the frameworks are good at this. The annotations compile down to PHP which you can look at directly, and you get exceptions if there is something wrong with the annotation. 2. (Decreased readability) - subjective POV. I find it easier, because the relevant configuration is next to the code to which it applies. It also prevents crufty out-of-date comments floating around. 3. (Yet another library) - Yep. No answer there. 4. (Icky feeling) - I get far more icky feelings out of seeing 30 lines of custom written 'setup code'. Annotations help to prevent that.

3 comments

It violates the "I don't need to look inside comments for sources of bugs" rule I'm quite fond of.

I've defended PHP for some time now, but this is getting ridiculous.

Isn't PHP embedded inside markup? Wouldn't it be simpler to do something like:

?> < ... XML GOES HERE ... > <?php

and not violate any expectations?

> It violates the "I don't need to look inside comments for sources of bugs" rule I'm quite fond of.

I second that. A practical explanation of why this is dumb idea.

I get it, PHP is about getting stuff done. But why insisting on bad ideas, when PHP already has lots of them.

no that's bad really.

The best way to write PHP for the web is like any language: php echos or prints shit, that's it.

The way you're showing is that of the total noob trying to implement some php inside their evil dreamweaver website.

Besides, if you're handling markup (in the web context) on the server side, you've already failed, as most markup should only be generated client-side, diminishing server-load and bandwidth consumed while greatly improving cacheability.

I strongly disagree. Echoing well-formated HTML is much harder than simply tagging around it, and what's the benefit of echoing it? You like escaping characters?
You didn't read the whole post.

1) your js should be echoing the HTML and getting data through JSON ajax

2) echo and print both work in command line, are explicit and work exactly as any language, whereas peppering your shit with php tags looks like shit and a maintenance nightmare.

If you have trouble escaping characters, you should consider the single quote, it's known to rock the boat.

Additionally, "'.$var.'" is the best, fastest, cleanest no surprise approach to inserting variables in markup, leaving double quotes just fine and dandy inside your markup.

And then, I'm pretty sure I'd rather have a string with 100% warranty of no execution or interpretation (that's single quote versus double quote for me) than any kind of dirty markup polluting my source code.

On the same subject, there is no valid reason for having naked markup inside your PHP, or between PHP tags because you're just begging for problems.

And I would expect multiple PHP tags to cause some minimal parsing overhead too.

Either way this matters not because the only sane way to use PHP in a web application is echo json_encode($return); or header(file) + readfile

And even then the second example is only there because javascript can't be arsed to support file creation/download (i.e. server -> blob.gz -> js -> would you like to dload this shit ?)

I would argue that it's better for configuration and application logic should be separate though. You can run the same appliation with a different XML configuration without modification of the source. You couldn't do the same with in-comment configuration.
Wherever this is likely to happen, I wouldn't use annotations. For example, I use YML for environment specific variables.

But I don't need routes or fieldnames to be different only in one environment, so annotations work great there.

Fair enough. Then it sounds like your problem is really with annotations, and not that much about the in-comment part of this.
Yes, and it's not limited to PHP. I don't particularly like how Flask (python) uses decorators for its routing as well.
3) In this specific case we're reliant on Doctrine to read Doctrine annotations because we're already reliant on Doctrine to be Doctrine. Possibly relevant if the annotation reader was purely collecting metadata it did not use itself.
Not necessarily. Several Symfony components rely on doctrine/common simply for parsing annotations, even if you are not using Doctrine for anything else.
Oh okay. I'd never noticed that because I've always got doctrine in use anyway. /me wanders off to look more closely at the components.
Witch clearly proves that is a bad idea because it injects a dependency on some other lib