Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75319
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 95.130.10.56 cause and error)
Message-ID: <53BAB8B0.5080208@hoa-project.net>
Date: Mon, 07 Jul 2014 17:11:44 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c9Fb0dswXcen8tnkQLEWhBymJ-w30z+p=vj3uRzdS3mGQ@mail.gmail.com> <CABBJUpcPO6fnmtCYjuD1iPqJdfn77R74Uie49Hr65WksY=mu+Q@mail.gmail.com> <4BB5E7E4-BCED-4271-BECC-804A1EDD4E53@ajf.me> <CABBJUpcqk3PvR9WSR+HhXPO0f9qObY2=DvqSQwnETA5sbhyeEA@mail.gmail.com>
In-Reply-To: <CABBJUpcqk3PvR9WSR+HhXPO0f9qObY2=DvqSQwnETA5sbhyeEA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Uniform Variable Syntax
From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa")

On 07/07/2014 16:54, Laruence wrote:
> On Mon, Jul 7, 2014 at 10:46 PM, Andrea Faulds <ajf@ajf.me> wrote:
>> On 7 Jul 2014, at 15:42, Laruence <laruence@php.net> wrote:
>>
>>> 1. "The current patch introduces a new =E2=80=9Cwrite context=E2=80=9D=
 issue. Namely
>>> ($foo)['bar'] =3D 'baz' will not behave this same was as $foo['bar'] =
=3D
>>> 'baz'. In the former case an undefined variable notice will be thrown=

>>> if $foo does not exist, whereas the latter does not throw a notice."
>>>
>>> 2. "As these changes only apply to some very rarely used syntax, the
>>> breakage seems acceptable for PHP 6."
>>>
>>>
>>> I don't think we should introduce a new thing which is not perfect or=

>>> "confused".. it looks like we fixed a mess with a new mess.
>>>
>>> it make me think we should : "don't fix it until it is broken=E2=80=9D=

>> We are fixing what is broken here; the variable syntax is counter-intu=
itive at the moment, and they make the syntax more consistent overall.
>>
>> Also, parentheses in PHP are always a source of issues. I don=E2=80=99=
t think they=E2=80=99ll ever quite work properly unless we switch to usin=
g an AST-based parser someday.
> then we won't need to temporarily fix it..
>
> anyway, it's just my 2 cents
While I deeply agree with you (introducing something we will need to fix =

later is not a good idea), this RFC fixes a lot of real, concrete and=20
immediate issues that are blocking for the emergence of new tools (for=20
example, a grammar of PHP that can be used by AST-compliant tools).=20
Moreover, it defines a clear base for the semantics of variables. Known=20
issues are well-spotted and define the very next steps of the work.=20
Parentheses are interpreted in various ways according to the language=20
and the area. Thus, a lot of (smart and calm) discussions will be=20
required. However, this RFC is targeting PHP6 (and not 7=E2=80=A6 just ki=
dding=E2=80=A6=20
or not=E2=80=A6 o_O), so we have time to fix the next spotted issues befo=
re the=20
final release. Let's cut the giant task into small ones. I think this is =

the approach of Nikita since he has honestly exposed the known issues.

Cheers :-).

--=20
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/