Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65996 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56517 invoked from network); 19 Feb 2013 21:43:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Feb 2013 21:43:00 -0000 Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222) Received: from [173.1.104.101] ([173.1.104.101:62268] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7E/BA-17768-2E1F3215 for ; Tue, 19 Feb 2013 16:42:59 -0500 Received: from localhost ([216.220.114.66]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id EXJ98355 for ; Tue, 19 Feb 2013 13:42:55 -0800 Date: Tue, 19 Feb 2013 16:42:46 -0500 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <1586876476.20130219164246@cypressintegrated.com> To: Peter Lind In-Reply-To: References: <5123BE51.7060500@oracle.com> <5123CE1E.5020500@lerdorf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) Seems this would complicate the transplanting of (global) functions into (default public) class methods and vice versa. This is a common refactoring task -- at least IME -- and before I adjust visibility I would expect the function to Just Work. So this works in a class to define the function: function my_function() { } And I expect to be able to pull that out into the global scope as-is. But if people start using this super-shorthand in the class: my_function() { } Then when I pull it out into my function library, I'll get errors. The reverse is also true: I expect to get a fatal from leaving off a semicolon between function_call() and {} but at the top level of a class it gets smoothly compiled as a function definition. Look, I know there are similar cases throughout PHP (and other languages) already, but why add more for no (IMO) payoff? Perhaps not the most compelling case against this new sugar, but it would suffice to stop me from ever using it. -- Sandy