Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64838 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56529 invoked from network); 11 Jan 2013 00:18:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jan 2013 00:18:56 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.183 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.183 smtp183.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.183] ([67.192.241.183:43305] helo=smtp183.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B0/B2-02684-E6A5FE05 for ; Thu, 10 Jan 2013 19:18:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 4DFBE83A5; Thu, 10 Jan 2013 19:18:52 -0500 (EST) X-Virus-Scanned: OK Received: by smtp8.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id EDF2580AD; Thu, 10 Jan 2013 19:18:51 -0500 (EST) Message-ID: <50EF5A6B.9010107@sugarcrm.com> Date: Thu, 10 Jan 2013 16:18:51 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nikita Popov CC: PHP internals References: <4ED7146272E04A47B986ED49E771E347BB3D6ABCB3@Ikarus.ameusgmbh.intern> <50EC5F8F.8010703@mrclay.org> <50EF3C9C.3020701@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > that statement in the RFC is still true. On this subject, are you > (personally) okay with the current approach for creating automatic > accessors (i.e. create PHP code string and compile)? It might be more efficient to generate the opcodes directly, since they are always the same and you'd really need to only plug the string into one place (or in case of typehints, two places), but I don't have preference one way or another, depending on which is easier. If we won't have reentrancy, line numbers, etc. issues then generating a string may be easier and also more robust if opcodes ever change. > Just to make sure I got it all right, you are suggesting: > * Parentheses must be used on all accessors, so it's set($value) {} and > get() {} and isset() {} and unset() {} and something like get {} is not > possible? > * Automatic accessors don't have parentheses so they are just set; get; > isset; unset; > > Is that right? If so, then I think it's a reasonable approach. Yes, I think this makes it look consistent - albeit at the price of some added verbosity. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227