Live data from Hacker News

PHP Annotations Are a Horrible Idea

theunraveler.com

121–127 of 127 posts

Re: PHP Annotations Are a Horrible Idea

#121
post #69
post #5

This is pure horse pucky. First of all PHP isn't about elegance and I find it a teeth grinding experience when people complain about it not being so. PHP is about getting stuff done. He doesn't offer one good valid technical reason why not to use comments for meta-programming PHP other than "it just feels wrong" and an "icky feeling" which is entirely subjective. "Reliance on Yet Another Library"? C'mon. The fact tha…

If annotations are in comments, how are you going to leave actual comments containing annotations that you don't want to actually affect the code?

Easily, the annotation parser ignores all comments that it doesn't recognise.

    /**
     * @var integer $id
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     * some comment that the doctrine parser will ignore completely
     */
    private $id;

Re: PHP Annotations Are a Horrible Idea

#122

Earlier quoted context omitted.

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: ?> and not violate any expectations?

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 band…

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?

Re: PHP Annotations Are a Horrible Idea

#123

Earlier quoted context omitted.

I find it's best to describe what the argument are, as short names are rarely enough, and the return values or values supplied to callbacks under various conditions. An example would be: "Verify account takes an account ID, an optional enabled flag which, if specified, will only search for accounts that have a matching enabled status. The default is to search against all accounts. The return value is true if the acco…

Wouldn't that kind of information be better expressed in machine-human-readbale formats outside of the code that can be used to not only convey the information to the reader, but also verify that the description does as it says it does? I will agree that some of that information is worth writing down, but I'm not yet convinced a comment within the code is the right place for it. > These are extremely important in loo…

The only "machine readable" comments I've seen that are useful are those structured in a simple, non-intrusive manner that makes generating documentation from them more automatic.

Remember that comments and documentation are no substitute for proper testing that will expose usage errors. No amount of machine readable specification can prevent this, so it's often a waste of programmer time to produce.

Re: PHP Annotations Are a Horrible Idea

#124
post #67
post #11

Closures inside property initializations inside the class body don't work. Not even in an array. So this code throws up a "Parse error: syntax error, unexpected 'function' (T_FUNCTION)" class User { public static $mapping = array( 'username' => array( 'type' => 'string', 'length' => 32, 'unique' => true, 'nullable' => function() { // Some logic to determine value. } ) ); }

Don't need to inline the function, it could instead just be a reference to static member of the same class: ... 'nullable' => self::getNullable, ...

'nullable' => self::getNullable

also won't work in any version of PHP

Re: PHP Annotations Are a Horrible Idea

#125

Earlier quoted context omitted.

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 band…

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 ?)

Re: PHP Annotations Are a Horrible Idea

#126

Earlier quoted context omitted.

Wouldn't that kind of information be better expressed in machine-human-readbale formats outside of the code that can be used to not only convey the information to the reader, but also verify that the description does as it says it does? I will agree that some of that information is worth writing down, but I'm not yet convinced a comment within the code is the right place for it. > These are extremely important in loo…

The only "machine readable" comments I've seen that are useful are those structured in a simple, non-intrusive manner that makes generating documentation from them more automatic. Remember that comments and documentation are no substitute for proper testing that will expose usage errors. No amount of machine readable specification can prevent this, so it's often a waste of programmer time to produce.

> Remember that comments and documentation are no substitute for proper testing that will expose usage errors.

Which is pretty much what I was getting at. Consider the following pseudo-code:

  Verify account takes an account ID, an optional enabled flag which, if
  specified, will only search for accounts that have a matching enabled
  status. The default is to search against all accounts. The return
  value is true if the account is valid, false otherwise.:

    account = new Account(id: 1)
    assert account.search does_not_include id != 1
It is human readable and machine parseable. You get your documentation, usage examples, and tests all in a place that is far better suited for the job, in my present opinion. I welcome being swayed though.

(I'm not sure that code even matches what your comment describes, but I couldn't really figure out what the comment was supposed to really intend the code to do, which brings me all the way back to my original points. Sorry.)

Re: PHP Annotations Are a Horrible Idea

#127

Earlier quoted context omitted.

Indeed, but what if you don't? I'm not saying that intuition is bad. I'm saying that intuition is bad when trying to make a reasonable point.

Sure. I read it as "there is something wrong with it, but I can't pinpoint what", which is fair enough in my book. It's not like this is the lynchpin of the article.

It's noise in disguise to me: filler to make it look like he has more arguments than he really has.
Post reply on HN