Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69749 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78907 invoked from network); 22 Oct 2013 09:53:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Oct 2013 09:53:14 -0000 Authentication-Results: pb1.pair.com smtp.mail=sebastian@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=sebastian@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 188.94.27.5 as permitted sender) X-PHP-List-Original-Sender: sebastian@php.net X-Host-Fingerprint: 188.94.27.5 scarlet.netpirates.net Received: from [188.94.27.5] ([188.94.27.5:35304] helo=scarlet.netpirates.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2E/EB-10840-40B46625 for ; Tue, 22 Oct 2013 05:53:13 -0400 Received: (qmail 20944 invoked by uid 89); 22 Oct 2013 09:53:08 -0000 Received: by simscan 1.4.0 ppid: 20936, pid: 20939, t: 0.0254s scanners: attach: 1.4.0 clamav: 0.97.6/m:55/d:17990 Received: from unknown (HELO ?192.168.179.21?) (team@thephp.cc@31.16.194.148) by scarlet.netpirates.net with ESMTPA; 22 Oct 2013 09:53:08 -0000 Message-ID: <52664B00.3030409@php.net> Date: Tue, 22 Oct 2013 11:53:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] [Vote] Keywords as identifiers From: sebastian@php.net (Sebastian Bergmann) On 10/22/2013 11:30 AM, Pierre Joye wrote: > I did not vote yet, however I agree with Derick. A cleaner solution > would be better. We have lived with this restriction for some time > already and we may as well delay this RFC until we have a viable > technical solution. If anyone feels motivated enough to implement the > parser/lexer using other tools :) The implementation has to be clean and the experience to users has to be consistent. Last time I looked at the RFC the implementation only allowed some keywords to be used in some contexts where keywords could not be used previously. Not allowing all keywords in all contexts only leads to confusion.