* I'm moving this into its own mail thread because talking about 5 different topics under the same chain is ridiculous (has anyone suggested forums instead of email??)
> So here comes my round of feedback on the current proposal. > > But before getting to that: I have collected a bit of data how getter and > setter are currently used in Symfony and ZF: > https://gist.github.com/3884203 Mainly so I get a better overview of the > situation, but might be of interest for other people involved > in this discussion too. > > So, my points on the proposal, in no particular order: > > 1. Typehints > ----------------- > > The last revision of the proposal added the ability to typehint the > set() accessor, so that's a good start. Still I would like to go a bit > further on this point. My data says that about 20-30% of all setters are > typehinted and it is highly probable that if we had scalar typehints (as I'm > sure we will have in the future) that number would be even > larger. In particular I would like to have an easy way to typehint if I > *don't* want to override any additional behavior. > Currently that would require me to write something along the lines of > this: > > protected $_date; > public $date { > get() { return $this->_date; } > set(DateTime $date) { $this->_date = $date; } > } > > This is a rather lot of boilerplate code just to add a typehint. With > automatic properties this might be reduced to this: > > public $date { > get(); > set(DateTime $date); > } > > This is already a lot nicer, because I don't have to implement the same > getting and setting pattern again and again, but I still find that it > doesn't do a particularly good job at conveying its intention. > Rather, what that code *really* wants to say is just this: > > public DateTime $date; > > I think that it would be very beneficial to support this syntax, because I > think that a large part of the use of the accessor proposal will > just be type checking. But if we indeed want to syntax we should reconsider > the get {} set { $value; } syntax again, because as I > understand it the new get() {} set($value) {} syntax was mainly introduced to > deal with setter typehints. If we chose to allow typehints > before the property name, then that wouldn't be necessary anymore. So the above would actually introduce an get/set accessor rather than a property, correct? If we were to abandon the long form ( set(DateTime $date) { ... } ) and go back to the original syntax, then the only way to "type hint" would be with no custom accessor logic, which I don't think makes sense. Jazzer also has said as much in a reply, so I think keeping the new syntax is required if we are going to support Typehints at all. I can agree though that the even further abbreviated syntax -> get/set accessor would be nice, however many have already pointed out that these "equivalents" reduce clarity, especially for the less "up to speed" of the developers. If they were to encounter that, they may have to really do some digging to realize that it's a "super auto implemented" accessor. I am not one to believe that is a reason not to support it, only that it may meet with a great amount of resistance. -Clint
