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 like it. It could be refined a bit syntax-wise, but I like it overall.
2. Yes. It doesn't seem to add much overhead noise, and is easy enough to maintain.
3. Irrelevant.
4. I don't know Python much, so again, irrelevant.

I will prefix this by saying I have come to the conclusion that I do not like the idea of accessors in general, regardless of how they implemented, I have a fundamental problem with the idea of hiding logic behind something that looks like simple property access. It is also difficult to be objective having examined the previous accessor proposal in depth. However, I will be as objective as possible under these circumstances.

1) I don't like it, primarily because it makes the declarations more complicated, not less. The idea of such a feature (for me) would be to make the use of "magic" setters and getters simpler, and this does not seem to deliver on that aspect. However I do agree that it is considerably cleaner than __get() and __set(), which usually result in an unreadable mess.

2) Objectively (assuming I actually wanted to treat the values as properties), probably yes. It would not be a big job, I could get EditpadPro to do most of the work with a couple of fairly simple regexes.

3) Not for me personally.

4) No. However the question seems to imply that I don't like the idea of annotations affecting the behaviour of the language, which is not the case. Many people seem to be of the opinion the annotations are akin to comments that affect behaviour, however I do not share this view.

1. I don't like the syntax, mainly because I feel the cognitive distance between a property and the accessor is too great. Meaning that I feel it's too far of a mental shift to go back and forth between variables, and random methods with a specific annotation.

2. No, because it offers no benefit over current implementations other than being able to access it as a property. With the currently proposed method, it offers the reduction of code. But this syntax still requires the code boilerplate, so there's no significant benefit that this provides me over current code, while the rejected proposal allows me to reduce actual executed code.

3. Not with this implementation of accessors.

4. No. While I think we should take features from other languages where they make sense, I don't feel that this feature makes sense (even in the context of python)...

1. Not a fan of the syntax. The @ syntax for annotations is sensible, but I wouldn't want to see it used as a means of denoting property accessors. Frankly, I think C# got it right. I foresee annotations needing a sort of delimiter, depending on how they'd be implemented.

class Foo {

    public $property {
        get { return 42; }
        set { throw new Exception(); }
    }

    @<annotation($name = 'value')>
    public function method() { /* ... */ }

}

2. Accessors, not with the proposed syntax or implementation. C# style accessors, then yes. Annotations, in general, yes.

3. No, syntactically it's too different, I don't think the benefits outweigh wrapping my head around it.

4. No. On a syntactic note, PHP being a C-style language (syntactically), I think borrowing syntax from other OO C-style languages would be the most reasonable.

---

Addendum: I forgot about the error suppression operator, but it doesn't change my answer. Instead, deprecate the error suppression operator. Whenever it's interpreted in class scope, it's an annotation. When it's removed, we can all sleep easier knowing that nobody can $foo = @$bar['qux'];

Question #1: @is the error supression operator in PHP. not that I like that operator, but it is an operator. Operators are pretty distinct, so, you can not introduce that operator for a secondary thing like annotations. Even I know it from tags within docblocks, this is not PHP code but comments. However you add @ to PHP code as comments (annotations), however this is PHP code so it's the error supression operator. This means what you outline does not work.

Question #2: No because as outlined in Question #1, your suggestion violates the language (I would not consider it a change if I would need to bold'en the argument. I know that's a stretch, but as long as you don't suggest to convert the PHP interpreter to some AST or JIT based on a popular compiler framework I would just say: NO and show you my tongue. Yeah, let's start sexy talk.)

Question #3: Rhetorical. Sure there would have been a value. We probably screwed it too early. So what? Who do we want to blame for the mistake? PHP's legacy? PHP's future? Come on, this is really a rhetorical question.

Question #4: Honestly I've never written a single line of Python code (okay actually I've written one and a half line of python code and did contribute in a popular software that was written in python with a bug-report and even a patch, however, why the hell do you ask? You want to say python is good? Python is bad? I bet, python is a pretty well made scripting language. It's probably not as popular as PHP, however, would you say Wordpress is a good example of a PHP based framework? There you got the answer. NO.

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.