Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69765
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.105 as permitted sender)
Message-ID: <BLU0-SMTP123AF1E34FC063D33DEA9B6E2020@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
In-Reply-To: <alpine.DEB.2.10.1310221325120.5542@whisky.home.derickrethans.nl>
Date: Tue, 22 Oct 2013 14:55:32 +0200
CC: Developers List PHP Mailing <internals@lists.php.net>,
 zeev@zend.com
Content-Transfer-Encoding: quoted-printable
References: <BLU0-SMTP246429F66DC7B144E131FE7E2010@phx.gbl> <alpine.DEB.2.10.1310221010490.5542@whisky.home.derickrethans.nl> <228247caf0dc0352a6c3f313193ea46a@mail.gmail.com> <DUB403-EAS85F76DB0B967920DFA7B98E2020@phx.gbl> <alpine.DEB.2.10.1310221325120.5542@whisky.home.derickrethans.nl>
To: Derick Rethans <derick@php.net>
Subject: Re: [PHP-DEV] [RFC] [Vote] Keywords as identifiers
From: bobwei9@hotmail.com (Bob Weinand)

Am 22.10.2013 um 14:28 schrieb Derick Rethans <derick@php.net>:
> On Tue, 22 Oct 2013, Bob Weinand wrote:
>> Am 22.10.2013 um 12:54 schrieb "Zeev Suraski" <zeev@zend.com>:
>>=20
>>> From: Derick Rethans [mailto:derick@php.net]
>>> Sent: Tuesday, October 22, 2013 12:12 PM
>>>=20
>>>> On Mon, 21 Oct 2013, Bob Weinand wrote:
>>>>>=20
>>>>> I have started the vote for extended keyword support RFC:
>>>>>=20
>>>>> https://wiki.php.net/rfc/keywords_as_identifiers
>>>>=20
>>>> Just to explain why I voted "no". I think the idea is good, but=20
>>>> what I see from the patch is that it adds a *lot* of hand written=20=

>>>> state machines which are going to be a pain to maintain. I do not=20=

>>>> think this extra maintenance is worth the features - we've done=20
>>>> pretty well without it.
>>>=20
>>> Thumbs up for the idea as well, but I don't think we can live with=20=

>>> the implementation.  BTW, that's a bit of a grey area but I think=20
>>> that even if an idea is accepted, if there's no reasonably clean=20
>>> implementation available for it, I don't think it can go in.
>>=20
>> As said, if anyone has a good idea how to improve the implementation,=20=

>> I'd be happy to implement it.
>=20
> That's not an excuse for adding code that people disagree with.

I agree, but if people disagree, then I'd like to hear which code they'd =
prefer.

>> Btw. Is my implementation so bad? I think it looks far worse than it=20=

>> is in reality...)
>=20
> You add 350 lines of almost-hand-crafted parsing to the lexer, which I=20=

> consider "modereately bad". My point is that I don't think it's worth=20=

> this extra complication for a "not really important" feature.


About 150 lines parsing, the other are macros and other logic.

Actually syntax is mostly:
if (buf_one_token =3D=3D T_TOKEN && LEX_IS_CUR_ALPH_TOKEN()) {
    LEX_CONVERT_CUR_STRING();
}

That's not much more complicated than just writing something like:

T_TOKEN ALPH_TOKEN {
    LEX_CONVERT_CUR_STRING();
}

in a bison/yacc parser.

___

Also, it is not a really complication; it's just a transparent =
additional step
you usually don't have to modify and could even remove without loosing
any features except the keyword support.

Bob Weinand=