Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65123
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender)
References: <510038C9.5000900@mrclay.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <510038C9.5000900@mrclay.org>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <B103E205-5F44-4524-9BCD-7BF241F7E552@zerocue.com>
Cc: PHP Internals <internals@lists.php.net>
Date: Wed, 23 Jan 2013 14:54:09 -0600
To: Steve Clay <steve@mrclay.org>
Subject: Re: [PHP-DEV] C# properties vs. accessors RFC
From: cpriest@zerocue.com (Clint Priest)

On Jan 23, 2013, at 1:23 PM, Steve Clay <steve@mrclay.org> wrote:

> First of all, I think the functionality provided by Clint and Nikita's RFC=
 [1] is in demand and would be an asset to PHP, but I also think it can repa=
ckaged more simply.
>=20
> People are comparing the RFC to C# [2], but while they look similar, C# ha=
s a simpler implementation we should learn from.
>=20
> 1. C# draws a firm line between property and field, keeping both concepts s=
imple.
>=20
> A "field" is like a PHP property. There's no more to understand.
>=20
> A "property" is simply a set of functions emulating a field, and $value is=
 available in the setter body. There's no more to understand.
>=20
> Importantly, I think, the property takes the place of a field; there's nev=
er a "shadow" field of the same name to think about. The obvious downside is=
 you must use a distinctly-named field for storage, but the upside is concep=
tual and behavioral simplicity. There's no need for "guarding" mechanisms an=
d rules about where "$this->prop" will mean field access or trigger getter/s=
etter; we know there is no field "prop", period.
>=20
> As Sharif Ramadan pointed out, it also makes state snapshots clearer as th=
ere is no value stored under "prop" to potentially confuse. Under the RFC, e=
very property would show up as a field *even if the accessors didn't use tha=
t field*.
>=20
> 2. C# has no issetter/unsetter.
>=20
> IMO customizing these functions is completely unneeded for the vast majori=
ty of use cases and could be replaced by simpler logic: isset($this->prop) c=
alls the getter and compares to NULL; unset($this->prop) passes NULL to the s=
etter.
>=20
> 3. C# has no auto-implementations.
>=20
> IMO auto implementations have some value removing boilerplate, but we shou=
ld not make them violate #1. We could have the property syntax specify what f=
ield to use for underlying storage, or simply conclude that the boilerplate i=
s worth the clarity.
>=20
>=20
> I think the path forward is to determine how we can serve the same goals a=
s this RFC, but retain the conceptual simplicity of the C# implementation an=
d maybe syntax that strays less from current PHP.
>=20
> I have some ideas that I could start forging into an RFC. Consider this:
>=20
> class Foo {
>  private $_bar;
>  public function get bar { return $this->_bar; }
>  public function set bar { $this->_bar =3D $value; }
> }
>=20
> Advantages I see over the RFC:
> * It's clearer that the accessors map to regular methods, and you know how=
 to control visibility of methods and how they're inherited.
> * It's clearer $bar doesn't exist as a property, and it will never show up=
 in state inspection.
> * You know $_bar is a plain PHP property, and you can initialize it direct=
ly in the constructor; we don't need an "initter".
> * There are no guards/proxies/shadow property to think about
>=20
> As for type-hinting, I think that could be achieved by a separate, simpler=
 mechanism: type-hinting the properties.
>=20
> class Foo {
>  private Bar? $_bar;
> }
>=20
> $_bar is a regular property, but which can only be set to a Bar or to null=
 ("?" implies nullable). That gives you simple typed properties (useful and s=
impler to understand without accessors), but also suggests how to combine th=
ese to get "typed accessors":
>=20
> class Foo {
>  // settable anywhere
>  public Bar $bar;
>=20
>  // "read only"
>  protected Baz? $_baz;
>  public function get baz { return $this->_baz; }
> }
>=20
>=20
> Down the road we could further address how to shorten this syntax but whil=
e keeping it clear that accessors are just functions and properties are just=
 value stores.
>=20
I'd just like to point out the fact that RFC v1.1 from a year ago was exactl=
y as above but people wanted all of these other features.  They were not a p=
roperty, they had no "guarding", no unset, isset, etc.=20

The original RFC that was exactly as c# had it, nobody liked it.

It was changed to its current incarnation because it now mimics exactly what=
 everyone is use to with __get(), etc.

>=20
> [1] https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
> [2] http://msdn.microsoft.com/en-us/library/x9fsa0sw(v=3Dvs.80).aspx
>=20
> Steve Clay
> --=20
> http://www.mrclay.org/
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20