Re: [RFC] [Vote] Keywords as identifiers

From: Date: Tue, 22 Oct 2013 12:55:32 +0000
Subject: Re: [RFC] [Vote] Keywords as identifiers
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-69765@lists.php.net to get a copy of this message
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>: >> >>> From: Derick Rethans [mailto:derick@php.net] >>> Sent: Tuesday, October 22, 2013 12:12 PM >>> >>>> On Mon, 21 Oct 2013, Bob Weinand wrote: >>>>> >>>>> I have started the vote for extended keyword support RFC: >>>>> >>>>> >>>>> https://wiki.php.net/rfc/keywords_as_identifiers >>>> >>>> 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. >>> >>> Thumbs up for the idea as well, but I don't think we can live with >>> the implementation. BTW, that's a bit of a grey area but I think >>> that even if an idea is accepted, if there's no reasonably clean >>> implementation available for it, I don't think it can go in. >> >> As said, if anyone has a good idea how to improve the implementation, >> I'd be happy to implement it. > > 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 >> is in reality...) > > You add 350 lines of almost-hand-crafted parsing to the lexer, which I > consider "modereately bad". My point is that I don't think it's worth > 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 == 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

« previous php.internals (#69765) next »