Annotations-Properties Questionnaire.md

Thank you to everyone who responded, both here and in various other places. I appreciate your feedback. The questionnaire will remain below for posterity's sake.

To clarify a few things:

• I did not intend to mean that we should/can use the @ symbol for annotations. I should have been more clear to state that this was about the idea of using annotations to dictate what is a setter, not on the exact details here. What symbol is used for annotations is fairly irrelevant if we don't like the idea of using them as a means to declare getters/setters, don't you think?
• I'm not sure why everyone likes C# syntax. It seeems that I am a lone man who believes that is a syntactic abomination.

---

##Greetings, minions of PHP!

I have some questions for all of you. They are regarding annotations in PHP. They also are regarding accessors/properties.

Question #1: What are your initial thoughts on the following (just initial thoughts: not a brain core dump):

class Foo {
   private $bar;

   @bar.getter
   public function getBar() { return $this->bar; }

   @bar.setter
   public function setBar($value) { $this->bar = $value; }

}

Note that this is not just meta-data; this would behave as follows:

$foo = new Foo();
$foo->bar = 42; // calls $foo->setBar(42);
$bar = $foo->bar; // calls $foo->getBar();

Question #2: Assuming that you had the following code in your codebase, would you go through the effort of transitioning to use accessors/adding the annotations?

class Foo {
   private $bar;

   public function getBar() { return $this->bar; }

   public function setBar($value) { $this->bar = filter($value); }

}

Question #3: Is the value gained by easily transitioning your code to use accessors worth the downsides you listed in response to question #1?

Question #4: Does the fact that Python has a syntax that uses annotations to define accessors change your mind at all?

1. I don't find it useful enough. The advantage of accessors is to replace getters/setters with default implementations, i.e. most cases should become:

class Foo {
   public $bar;
}

In theory, this is possible with your solution, but an analysis had been done on Symfony2 and ZF2 code base and it showed that most of the setters were here for typehinting.

So unless

class Foo {
   public Bar $bar;
}

becomes possible, this solution is not answering the need.

And to bounce on ircmaxell comment, the getters and setters are "far" from the property. This is annoying as hell in current code. I prefer C#-style accessors.

Lastly, the annotations are a real problem for PHP, there at discussion for a long time. I'd love to have them, but this kind of solution will raise that question also and this will never work: this is too much much internals ;)

2. Probably not. The problem is mostly with the usage of the property: having to replace the getter/setters calls is long. So I guess this would be the same answer whatever the solution for accessors. Only new/small projects or new code would use accessors for me.

3. Yes this is useful that the migration is easier, but for me that's not playing a lot. I want that functionality for the future projects mostly.

4. It makes it more acceptable (let's be honest), but that's not weighing a lot in the decision.

PS: I am 100% wanting accessors in PHP, I just don't think this solution is better than C# style accessors.

1. This looks horrible. I can't prevent my brain from dumping a few things:

• The problem of "spatial distance" is still present. In my opinion, the property should enclose its accessors.

• Futhermore, there are unnecessary redundancies, which over-complicate readability. Iam talking about:

  $bar
  @bar.getter
  getBar
  @bar.setter
  setBar
  

  Reading five times "bar" and two times "set" and "get". Just compare it to:

  $bar
  get
  set
  

  No redundancies and a lot easier to read.

• The "@" is already an operator in a different context (error handling).

2. In general, yes. But not with the proposed annotation syntax. +1 for RFC v1.2 / C# style.
3. Definitely not.
4. No.