Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69797
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5267162E.6010705@php.net>
References: <BLU0-SMTP246429F66DC7B144E131FE7E2010@phx.gbl>
 <alpine.DEB.2.10.1310221010490.5542@whisky.home.derickrethans.nl>
 <5266E17F.40700@sugarcrm.com> <5267162E.6010705@php.net>
Date: Wed, 23 Oct 2013 00:38:45 -0400
Message-ID: <CAFp73XvUhLc_ZPk7rHt8=6fAjEpOkgF9tLToUajvpSnZpuMmJg@mail.gmail.com>
To: Clint Priest <cpriest@php.net>
Cc: Developers Mailing List PHP <internals@lists.php.net>, Bob Weinand <bobwei9@hotmail.com>
Content-Type: multipart/alternative; boundary=047d7b6d95eef9d1f104e961181c
Subject: Re: [PHP-DEV] [RFC] [Vote] Keywords as identifiers
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--047d7b6d95eef9d1f104e961181c
Content-Type: text/plain; charset=UTF-8

+1 on idea
-1 on implementation


On Tue, Oct 22, 2013 at 8:19 PM, Clint Priest <cpriest@php.net> wrote:

> I just wanted to +1 for the idea but agree with Stas, Derrick and Zeev on
> the implementation, a simpler way needs to be found to solve the problem.
>
>
> On 10/22/2013 3:35 PM, Stas Malyshev wrote:
>
>> Hi!
>>
>>  Just to explain why I voted "no". I think the idea is good, but what I
>>> see from the patch is that it adds a *lot* of hand written state
>>> machines which are going to be a pain to maintain. I do not think this
>>> extra maintenance is worth the features - we've done pretty well without
>>> it.
>>>
>> Exactly the same here. I love the idea, but looking at the code I
>> realize even with my experience about what's going on in the engine I
>> have hard time understanding what's going on there, and we're not
>> talking about some obscure nook of the engine - parser is right in the
>> middle of everything. So I personally adding so much complexity is not
>> worth the cost. If we can find a solution to do the same (or roughly the
>> same, sacrificing some less important features) without adding so much
>> complexity it'd be much better I think.
>> Maybe if you made a good narrative explanation what's going on in that
>> code and it turned out it's not as bad as it looks and we just didn't
>> realize it, it would be more acceptable.
>>
>
>


-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--047d7b6d95eef9d1f104e961181c--