Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63388
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B5753@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B53E4@MBX202.domain.local>
	<CAF+90c9Sb786Cg=jBS=HUMkWaX60XGKNhVPUqrcoU7pQaub_=A@mail.gmail.com>
	<9570D903A3BECE4092E924C2985CE485612B5753@MBX202.domain.local>
Date: Sat, 13 Oct 2012 11:58:38 +0200
Message-ID: <CAF+90c_inuN6QFA-9KDX-qfGhJyHeziBtfkwqsMfRgP7oqj60w@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
From: nikita.ppv@gmail.com (Nikita Popov)

On Sat, Oct 13, 2012 at 6:47 AM, Clint Priest <cpriest@zerocue.com> wrote:
> The problem with that Nikita is that it would need a variable storage loc=
ation, which would mean a hidden, auto-implemented property.  You were dead=
-set against that from the get go.
What I was mainly against was the particular way how automatic
properties were implemented (with a real __property as a protected
backing field, which was directly exposed to the user). But automatic
properties don't really need that, or at least I don't see why. Just
"public $foo { get; set; }" doesn't really need anything, it can be
equivalent to "public $foo" (not that it makes much sense having it in
that case ^^). "public $foo { get; protected set; }" can also be
implemented without automagically generated accessor methods. This is
what Amaury's patch does, just with a different syntax (it provides
more detailed visibility handling, but does not need accessors).
Another reason why it might be better to not use generated accessors
for this, but rather just more detailed visibility flags for
properties, is performance. Right now "public $foo" would be a "fast"
property, but "public $foo { get; protected set; }" would turn it into
a "slow" method based property. Not sure how important that is though
:)

> Keep in mind that property accessors are not properties, real properties =
will take over the accessor, this could only be done from within the setter=
 of an accessor, but there isn't any way to create an accessor named $Hours=
 which accesses a variable named $Hours.
"Isn't a way" as in "not possible in the current implementation" or as
in "not possible due to technical limitations in the engine"? I was
going to suggest to allow accessing the $foo property from within the
$foo accessor as to avoid having to create a separate protected
backing property. But if that's not possible for technical reasons
then that obviously won't work out :/

> In any case, your example below could be implemented without automatic cr=
eation simply by doing the backing yourself, such as:
>
> private $myFoo;
>
> public $foo {
>         get() { return $this->myFoo; }
>         protected set($x) { $this->myFoo =3D $x; }
> }
Yes, sure you can implement it manually. Automatic properties are only
there to make it simpler. I can't exactly judge just how important
asymmetric visibility will be, so I don't know just how important it
is to make it short and easy. I can tell that Symfony has 3x more
getters than setters and ZF has 1.6x more getters. But I'm not sure
whether this means "many properties with asymmetric visibility" or
"many properties with just a getter".

> Shall I hold off on this discussion point before proceeding?
Yes, please. As there isn't really a consensus on this it would be
better to wait a bit more.

Nikita