Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63387
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEPJdu=1_TWqzyf+sKep+0zBMMJnWjw4R=WM8R95fC=S4UOSXg@mail.gmail.com>
References: <9570D903A3BECE4092E924C2985CE485612B53E4@MBX202.domain.local>
	<CAEPJdu=1_TWqzyf+sKep+0zBMMJnWjw4R=WM8R95fC=S4UOSXg@mail.gmail.com>
Date: Sat, 13 Oct 2012 11:29:50 +0200
Message-ID: <CAF+90c-OAcgv6kjg4Xy4acskQ6+35yfPq_hx5+oxPJn-EaaPsg@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Clint Priest <cpriest@zerocue.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
From: nikita.ppv@gmail.com (Nikita Popov)

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