On Sat, Oct 13, 2012 at 11:29 AM, Nikita Popov <nikita....@gmail.com> wrote:
> On Sat, Oct 13, 2012 at 10:06 AM, Benjamin Eberlei <kont...@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;
>
Ah yes, of course. Sorry, stupid me :-)
>
> 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
>
