Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63408
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.54 as permitted sender)
To: "internals@lists.php.net" <internals@lists.php.net>
CC: "Nikita Popov (nikita.ppv@gmail.com)" <nikita.ppv@gmail.com>
Thread-Topic: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints /
 Accessor Syntax
Thread-Index: Ac2qzY+DOufQVWL6SD+H4hb0hYe1Qw==
Date: Mon, 15 Oct 2012 12:11:33 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE485612B6434@MBX202.domain.local>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_9570D903A3BECE4092E924C2985CE485612B6434MBX202domainloc_"
MIME-Version: 1.0
Subject: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints /
 Accessor Syntax
From: cpriest@zerocue.com (Clint Priest)

--_000_9570D903A3BECE4092E924C2985CE485612B6434MBX202domainloc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

* I'm moving this into its own mail thread because talking about 5 differen=
t topics under the same chain is ridiculous (has anyone suggested forums in=
stead of email??)



> So here comes my round of feedback on the current proposal.

>

> But before getting to that: I have collected a bit of data how getter and=
 setter are currently used in Symfony and ZF:

> https://gist.github.com/3884203 Mainly so I get a better overview of the =
situation, but might be of interest for other people involved

> in this discussion too.

>

> So, my points on the proposal, in no particular order:

>

> 1. Typehints

> -----------------

>

> The last revision of the proposal added the ability to typehint the

> set() accessor, so that's a good start. Still I would like to go a bit fu=
rther on this point. My data says that about 20-30% of all setters are

> typehinted and it is highly probable that if we had scalar typehints (as =
I'm sure we will have in the future) that number would be even

> larger. In particular I would like to have an easy way to typehint if I *=
don't* want to override any additional behavior.

> Currently that would require me to write something along the lines of

> this:

>

>     protected $_date;

>     public $date {

>         get() { return $this->_date; }

>         set(DateTime $date) { $this->_date =3D $date; }

>     }

>

> This is a rather lot of boilerplate code just to add a typehint. With aut=
omatic properties this might be reduced to this:

>

>     public $date {

>         get();

>         set(DateTime $date);

>     }

>

> This is already a lot nicer, because I don't have to implement the same g=
etting and setting pattern again and again, but I still find that it

> doesn't do a particularly good job at conveying its intention.

> Rather, what that code *really* wants to say is just this:

>

>     public DateTime $date;

>

> I think that it would be very beneficial to support this syntax, because =
I think that a large part of the use of the accessor proposal will

> just be type checking. But if we indeed want to syntax we should reconsid=
er the get {} set { $value; } syntax again, because as I

> understand it the new get() {} set($value) {} syntax was mainly introduce=
d to deal with setter typehints. If we chose to allow typehints

> before the property name, then that wouldn't be necessary anymore.


So the above would actually introduce an get/set accessor rather than a pro=
perty, correct?  If we were to abandon the long form ( set(DateTime $date) =
{ ... } ) and go back to the original syntax, then the only way to "type hi=
nt" would be with no custom accessor logic, which I don't think makes sense=
.  Jazzer also has said as much in a reply, so I think keeping the new synt=
ax is required if we are going to support Typehints at all.



I can agree though that the even further abbreviated syntax  -> get/set acc=
essor would be nice, however many have already pointed out that these "equi=
valents" reduce clarity, especially for the less "up to speed" of the devel=
opers.  If they were to encounter that, they may have to really do some dig=
ging to realize that it's a "super auto implemented" accessor.



I am not one to believe that is a reason not to support it, only that it ma=
y meet with a great amount of resistance.

-Clint

--_000_9570D903A3BECE4092E924C2985CE485612B6434MBX202domainloc_--