Live data from Hacker News

PHP Annotations Are a Horrible Idea

theunraveler.com

41–50 of 127 posts

Re: PHP Annotations Are a Horrible Idea

#41
post #13

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

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.

Fair enough. Then it sounds like your problem is really with annotations, and not that much about the in-comment part of this.

Re: PHP Annotations Are a Horrible Idea

#42
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…

Here's a good, valid, technical reason: any meta-programming tool – even a well-designed one – that strips out comments will now change the meaning of your code and silently fail.

If the annotation were instead, say, not inside the comments, then any such tool would either (a) leave the annotation intact, or (b) fail with an error when it encounters the unknown syntax.

Re: PHP Annotations Are a Horrible Idea

#43
I fail to see how an array makes debugging say a routing directive easier. The issue is generally incorrect names or values which will not be aided by a backtrace or a var_dump - you know the value in either scenario. You will still have to dive into the parser and understand what it's looking for to resolve your problem or delve into XDebug.

In the situations when knowing the value of something does not help, I do not see why annotations wouldn't be superior.

Re: PHP Annotations Are a Horrible Idea

#44
That article misses the point:

PHP OO is a HORRIBLE IDEA. if you're doing OO PHP, shoot your other foot right now and go learn PHP before using it java-style.

Why is it that every time somebody on HN explains that a technology is not suitable for a use case, it gets downvoted by fans of said technology ?

Re: PHP Annotations Are a Horrible Idea

#45

Comments should be comments only, but your code in "alternative" is very dirty. Static(!) public(!) property is violation of encapsulation.

I don't understand how. It's a static property because it applies to all object of the class, not an individual object (i.e. an individual object shouldn't be able to change it).

And how is making the property public a bad idea? The configuration system that parses it will need to read the property, no? And a method like getUsername() should be reserved for actually getting the value of that field, not its config.

Re: PHP Annotations Are a Horrible Idea

#46

Earlier quoted context omitted.

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.

Re: PHP Annotations Are a Horrible Idea

#47
post #36
post #14

Earlier quoted context omitted.

I disagree. > First of all PHP isn't about elegance...PHP is about getting stuff done. What language isn't about getting stuff done? > He doesn't offer one good valid technical reason why not to use comments... Not true. The OP explicitly points out that it breaks many PHP debugging capabilities. > The fact that you can even parse out comments with the reflection API lends, to me, that meta-programming is a-ok. So wh…

Many of the OPs complains have the tone of "not my PHP!!!". If old PHP devs learn to look for annotations, points 2 and 4 no longer apply, and many points in 1 no longer apply either. It sounds more like a PHP dev grumbling about change... (what else is new)

I am not opposed to change--in fact, I welcome it, especially with regard to PHP. Rather, I'm criticizing the use of annotations based on the argument that it is bad application design.

Re: PHP Annotations Are a Horrible Idea

#48

I fail to see how an array makes debugging say a routing directive easier. The issue is generally incorrect names or values which will not be aided by a backtrace or a var_dump - you know the value in either scenario. You will still have to dive into the parser and understand what it's looking for to resolve your problem or delve into XDebug. In the situations when knowing the value of something does not help, I do n…

At least you would know if your array contains a syntax error. With an annotation, you would have no way of knowing that aside from what the annotation parser spits out.

Re: PHP Annotations Are a Horrible Idea

#49
Seriously, what sort of argument is this... (Allow me to paraphrase) "PHP doesn't have annotations, so instead it has hacked up comments that stand in for annotations. I find these ugly because it's abusing comments/etc therefore the idea of having a non-ugly real implementation that removes most of my objections is a bad idea"

--EDIT I may have slightly not realised it was just comment annotations that were the problem here rather than annotations as a whole.... HOLD FIRE.

Re: PHP Annotations Are a Horrible Idea

#50
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. } ) ); }

Came here to post the same thing. I don't know if it has been fixed in 5.4, though.

Nope, the parser seems to be pretty brittle around this. Someone who knows more about the internals can probably explain why this works:

  class User
  {
      public $mapping = array(
          'username' => array(
              'type' => 'string',
              'length' => 32,
              'unique' => true,
          )
      );  

      public function __construct()
      {
      	$this->mapping['nullable'] = function() { echo "test"; };
      	$this->mapping['nullable']();
      }
  }

  $user = new User();
And this doesn't:

  class User
  {
      public static $mapping = array(
          'username' => array(
              'type' => 'string',
              'length' => 32,
              'unique' => true,
          )
      );  

      public static function set()
  	{
  		self::$mapping['nullable'] = function() { echo "test"; };
  		self::$mapping['nullable']();
  	}
  }

  User::set();
Post reply on HN