Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71960
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.160.51 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAGAGxbZBk7yRjfKHrVKPKkyDEhSRBmaoJFc63KZxOyw7fyNs_Q@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>
	<CAGAGxbZBk7yRjfKHrVKPKkyDEhSRBmaoJFc63KZxOyw7fyNs_Q@mail.gmail.com>
Date: Sat, 1 Feb 2014 17:29:45 -0800
Message-ID: <CAESVnVpYUBBs9F=OkO0B1HrDjj8TjshiaOw9o_7fHjjzT1rWNg@mail.gmail.com>
To: Chris Wright <daverandom@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: pollita@php.net (Sara Golemon)

On Sat, Feb 1, 2014 at 2:55 PM, Chris Wright <daverandom@php.net> wrote:
> 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).
>
Correction: I want PHP code to be runnable anywhere, regardless of
which platform it was written for.  It makes me sad that so few people
on this list seem to care about cross-compatibility.

> 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.
>
Thank you.  This is what I was asking for.  A reason that was
something more than "HHVM does it so we have to do it differently."

That said, I don't like the look of [1] as it blurs the line between
the lexer and the parser.
The conflict with [2] is a 100% legit argument though.

> 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.
>
Again.  Don't put words in my mouth.  I never said anything about
blocking a PHP feature based on a conflict with HHVM.  Stop putting
words in my mouth. Stop it.

> 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).
>
"So much the better" is my point.  I've said repeatedly that "because
hhvm does it" is not enough reason for PHP to do it.  HOWEVER, it is
reason to try to steer the implementations closer together, not drive
them apart.

> [1] https://wiki.php.net/rfc/keywords_as_identifiers
> [2] https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
>