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;
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
