Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63395
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.40 as permitted sender)
To: Nikita Popov <nikita.ppv@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
Thread-Index: Ac2oOZ3+vAOzWRcnRpOb6a/hOVK5+AATwXAAAB0xg5AAE1uMAAAEUU8g
Date: Sat, 13 Oct 2012 12:47:11 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE485612B5A41@MBX202.domain.local>
References: <9570D903A3BECE4092E924C2985CE485612B53E4@MBX202.domain.local>
	<CAF+90c9Sb786Cg=jBS=HUMkWaX60XGKNhVPUqrcoU7pQaub_=A@mail.gmail.com>
	<9570D903A3BECE4092E924C2985CE485612B5753@MBX202.domain.local>
 <CAF+90c_inuN6QFA-9KDX-qfGhJyHeziBtfkwqsMfRgP7oqj60w@mail.gmail.com>
In-Reply-To: <CAF+90c_inuN6QFA-9KDX-qfGhJyHeziBtfkwqsMfRgP7oqj60w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
From: cpriest@zerocue.com (Clint Priest)

> > On Sat, Oct 13, 2012 at 6:47 AM, Clint Priest <cpriest@zerocue.com> wro=
te:
> > The problem with that Nikita is that it would need a variable storage l=
ocation, which would mean a hidden, auto-implemented property.  You were de=
ad-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 pro=
perties 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 equiv=
alent to "public $foo" (not that it makes much sense having it in
> that case ^^). "public $foo { get; protected set; }" can also be implemen=
ted 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
> :)
>=20
> > Keep in mind that property accessors are not properties, real propertie=
s will take over the accessor, this could only be done from within the sett=
er of an accessor, but there isn't any way to create an accessor named $Hou=
rs 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 $fo=
o accessor as to avoid having to create a separate protected
> backing property. But if that's not possible for technical reasons then t=
hat obviously won't work out :/
>=20
As it is presently written, if there is a real $foo property and a real $fo=
o accessor, the $foo accessor is never called.  This works exactly like it =
would if it were __get(), in the code where __get() would be called, a chec=
k is made for an getter with the name $foo and if it is exists, that is cal=
led in lieu of __get.  This aspect is also why lazy loading can work.  If y=
ou have an accessor $foo with a getter that "lazy loads" something expensiv=
e and then sets $foo (via its own setter), the next time $foo is accessed i=
t is a regular, standard public property and the "lazy load" never gets cal=
led again (unless the real property is unset). =20

> > In any case, your example below could be implemented without automatic =
creation 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 th=
ere to make it simpler. I can't exactly judge just how
> important asymmetric visibility will be, so I don't know just how importa=
nt 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".
>=20
> > 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.
>=20
> Nikita

So it sounds to me like you aren't looking for "auto implementation" but ra=
ther asymmetric visibility for properties... (aka Amaury's feature).

One of my design goals was to *not* create an additional "memory store" for=
 each accessor as this is not what other languages do, this is also why the=
 auto implementation created a separate memory store, so that every other a=
ccessor that didn't need to store data of its own would be free from the me=
mory overhead of having an unused memory spot.

public $foo { get; protected set; } wouldn't be a problem to be translated =
to mean "I don't really want an accessor, I want to define asymmetric visib=
ility on a property," the difficulty is what to do when something like this=
 is defined:

public $foo { get; protected set($x) { ... } }

Now we have a difficult situation.  There is a real property of $foo so no =
getter is called, it is referenced directly and in the case of setting it, =
clearly the desired functionality given the definition is that the setter w=
ould be called if $foo is attempted to be set within the right visibility s=
cope.  The difficulty is that to make the above work, accessors and propert=
ies must merge, a getter and setter check must be made on any property acce=
ss which will slow things down. =20

This is why, right now, properties and accessors are separated concepts, so=
 that there is no additional over-head for real properties.