Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71951
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <CAESVnVp0EaUvADdEqYG5FjQmn-Qifjycm0LaeG0L_YJBLa-fMQ@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>
Date: Sat, 1 Feb 2014 22:55:08 +0000
Message-ID: <CAGAGxbZBk7yRjfKHrVKPKkyDEhSRBmaoJFc63KZxOyw7fyNs_Q@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Gordon Oheim <gooh@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [VOTE] Automatic Property Initialization
From: daverandom@php.net (Chris Wright)

Sara

On 1 February 2014 19:53, Sara Golemon <pollita@php.net> wrote:
> On Sat, Feb 1, 2014 at 11:43 AM, Gordon Oheim <gooh@php.net> wrote:
>> On 01.02.2014 20:25, Sara Golemon wrote:
>>> FYI, I'm voting "No" as I don't think
>>> https://wiki.php.net/rfc/constructor-promotion was considered
>>> adequately.  They both seek to accomplish the same goal, but one
>>> introduces conflicting syntax while the other does not.
>>>
>>> If we're to go with the conflicting syntax, I'd like to see a
>>> reasonable argument why.
>>>
>> How is it conflicting?
>>
> Because it's different from already existing syntax (Code exists in
> the wild using HHVM's version of the syntax -
> https://wiki.php.net/rfc/constructor-promotion ).  I'm not sure which
> part you're confused about.

It seems to me that there is no direct conflict here, the two are not
fundamentally incompatible and could quite comfortably co-exist in
HHVM (which is I guess the issue here - you want to ensure that HHVM
can run pure PHP - since there is already a lot of syntax in HHVM that
cannot make the transition the other way).

By contrast, the HHVM syntax *does* conflict with the recent extended
keyword support RFC [1], and as a passive observer to the discussion I
gauged a fairly positive reaction to this conceptually, the reason it
was rejected was largely because the implementation was not up to
standard - maybe I misread this but still, I don't recall this
conflict being brought up at the time. The HHVM syntax would also make
any future implementation of something like the recent property
accessors RFC [2] difficult to mix in.

I love some of things you guys have done with HHVM, but I don't like
the idea of the HHVM implementation of something blocking an alternate
route to the same goal suggested for PHP (especially when there is no
direct conflict) - otherwise we may as well just throw PHP development
out of the window and let the HHVM team decide where we go.

I realise I've made barely anything in the way of material
contributions to PHP, but even looking at it strictly from the point
of view of a user, I know I'm not alone in wanting PHP to do what PHP
does, and not necessarily what HHVM does (but if they coincide, so
much the better).

[1] https://wiki.php.net/rfc/keywords_as_identifiers
[2] https://wiki.php.net/rfc/propertygetsetsyntax-v1.2

Thanks, Chris