Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71979
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVqVGz043r1qNDEHFLbt8mw2XR-Jk1mWA6FW5WuHMNz30Q@mail.gmail.com>
References: <98.E0.35265.E17FBE25@pb1.pair.com>
	<CAESVnVrRQO=fQyLBKjomn00DK3fivFYT6qBQOGb1yxdQmBur=w@mail.gmail.com>
	<CF.64.30967.E7E4DE25@pb1.pair.com>
	<CAESVnVp0EaUvADdEqYG5FjQmn-Qifjycm0LaeG0L_YJBLa-fMQ@mail.gmail.com>
	<52ED66CC.8070304@ajf.me>
	<CAESVnVouz_H-0nHpWaWUeRpnujCf3Yz5MhEmZD_kY7JoevkM3Q@mail.gmail.com>
	<52ED9D74.8080807@ajf.me>
	<CAESVnVpQXhDDh7iscC56jSTtfOrXj5acZ3AZFxAk+LSaz2V1xQ@mail.gmail.com>
	<CAEPJdu=VN1h=7JMECZ_D0uJc-_Y3PXh5r3TDVpMWgUpB2UdtHA@mail.gmail.com>
	<CAESVnVqVGz043r1qNDEHFLbt8mw2XR-Jk1mWA6FW5WuHMNz30Q@mail.gmail.com>
Date: Sun, 2 Feb 2014 10:25:29 +0100
Message-ID: <CAB6YZuzTbfzuOZ6nYygtADqnAMMz6VNtUsgHF9A79b_OYDFfeA@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, Andrea Faulds <ajf@ajf.me>, Gordon Oheim <gooh@php.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] Automatic Property Initialization
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

On Sun, Feb 2, 2014 at 3:46 AM, Sara Golemon <pollita@php.net> wrote:
> On Sat, Feb 1, 2014 at 6:06 PM, Benjamin Eberlei <kontakt@beberlei.de> wrote:
>> Imho HHVMs syntax has the massive flaw that you cannot use docblocks on
>> those properties anymore, which is not the case with this RFC. All other
>> things equal, this is why this RFC should clearly be favored.
>>
>> Also with typehints or - unlikely but possible - property-accesors the hhvm
>> syntax will become very verbose for the __construct line, wheras this RFC
>> can handle those cases without having to think about future compatibility.
>>
> Inclined to agree on the matter of getters/setters (though I regard
> the docblock issue as trivially solvable, and the typehint/verbosity
> issue as a non-issue).
>
> I've opened a discussion in the hhvm.dev group to look into this from
> that side, and removed my "No" vote for the time being. (I'm not sold
> on a "Yes" vote, however, as I'm not sure this buys us enough in its
> proposed form).
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

And how do you think the docblock issue could be trivially solvable?
Not from implementation POV,
but from syntactic POV?

Because I really don't want to write something like this:

/**
 * @prop string $email @ORM\Column(type="string", unique=true)
@Assert\NotEmpty @Assert\Email
 * @prop string $username @ORM\Column(type="string", unique=true)
@Assert\NotEmpty
 */
public function __construct(private $email, private $username) { }

Sure, it saves tons of lines of code from the classic docblock over
class field approach, but it is not as easily
readable. One docblock per line seems infinitely better to me.

Also I'm not sure if it's OK to "reveal" internal class implementation
via docblock and constructor parameters.