Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69781 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67899 invoked from network); 22 Oct 2013 20:35:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Oct 2013 20:35:17 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.91 smtp91.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.91] ([108.166.43.91:40038] helo=smtp91.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 41/8C-10840-381E6625 for ; Tue, 22 Oct 2013 16:35:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 85AA11412BD; Tue, 22 Oct 2013 16:35:13 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 2A50F140167; Tue, 22 Oct 2013 16:35:13 -0400 (EDT) Message-ID: <5266E17F.40700@sugarcrm.com> Date: Tue, 22 Oct 2013 13:35:11 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Derick Rethans , Bob Weinand CC: Developers Mailing List PHP References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] [Vote] Keywords as identifiers From: smalyshev@sugarcrm.com (Stas Malyshev) 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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227