Re: Property Accessors v1.2

On Sat, Oct 13, 2012 at 10:06 AM, Benjamin Eberlei <kontakt@beberlei.de> wrote: > Can we discuss the removal of automatic get; set; again? For me that was > the best feature of the whole RFC, essentially allowing to define a > property with getter/setter in 1 LOC. Allowing future overriding of that > getter/Setter if the application required it. > > This is absolutely essential for database backed recods which will have > tons of those property accessors. Now if i apply PSR coding styles to > accessors, then i end up with 11 LOC for accessors defining a property, a > property accessor and get/set functions, compared to 10 LOC with usual > getter/setters. Not sure I quite understand you. What prevents you from just using a normal public property? public $property; Accessors give you the ability to add alternative behavior for the property lateron (this is actually the main use I personally see in this RFC: Not actually using it, but having the possibility of using it). The only place (which I see off the top of my head) where property / automatic property makes a difference is interfaces. In the current implementation interfaces can only define properties with accessors. So: interface Foo { // this is okay public $abc { get; set; } // this is invalid public $abc; } And similarly you can't implement the public $abc { get; set; } definition from the interface using a plain property. I think that properties should be definable in interfaces, or at a normal property "public $abc;" should satisfy the interface "public $abc { get; set; }" (I mean, it kinda does from a functional point of view, right?) Nikita