Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50672 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1001 invoked from network); 28 Nov 2010 21:04:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Nov 2010 21:04:43 -0000 Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.96 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 76.96.30.96 qmta09.emeryville.ca.mail.comcast.net Received: from [76.96.30.96] ([76.96.30.96:50506] helo=qmta09.emeryville.ca.mail.comcast.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/E1-18134-AE3C2FC4 for ; Sun, 28 Nov 2010 16:04:42 -0500 Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta09.emeryville.ca.mail.comcast.net with comcast id cjTu1f0061afHeLA9l4fyi; Sun, 28 Nov 2010 21:04:39 +0000 Received: from earth.ufp ([98.220.236.211]) by omta17.emeryville.ca.mail.comcast.net with comcast id cl4e1f00U4aLjBW8dl4fFp; Sun, 28 Nov 2010 21:04:39 +0000 Received: from localhost (localhost [127.0.0.1]) by earth.ufp (Postfix) with ESMTP id 6EB0AD7A51 for ; Sun, 28 Nov 2010 15:04:38 -0600 (CST) Received: from earth.ufp ([127.0.0.1]) by localhost (earth.ufp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOe1r2TXmODo for ; Sun, 28 Nov 2010 15:04:38 -0600 (CST) Received: from linux-nkec.site (unknown [192.168.42.1]) by earth.ufp (Postfix) with ESMTPSA id 5A8E2D7A48 for ; Sun, 28 Nov 2010 15:04:38 -0600 (CST) To: internals@lists.php.net Date: Sun, 28 Nov 2010 15:05:24 -0600 User-Agent: KMail/1.13.5 (Linux/2.6.34.7-0.5-desktop; KDE/4.4.4; x86_64; ; ) References: <1290879624.7033.826.camel@guybrush> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-ID: <201011281505.24417.larry@garfieldtech.com> Subject: Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations From: larry@garfieldtech.com (Larry Garfield) On Sunday, November 28, 2010 9:12:34 am Felipe Pena wrote: > 2010/11/28 Ross Masters > > > From what I understand T_FUNCTION would be optional, rather than removed > > altogether, is this the case? This would allow those who want to use it > > the option of using it and would not break existing code. > > Yes, exaclty... File me -1. The above argument is oft-used but is not, in fact, a valid argument unless all of the code you work with is your own. The minute you start using 3rd party code (you know, sharing generic libraries in good software engineering and open source etiquette) you are at the whim of whatever syntactic "options" they chose to use. Optional "function", strict typing, exceptions, the list goes on. There is no such thing as an "optional" language feature if you're working with code you didn't write. Given that, making "functional" optional makes the language more complex (for me visually scanning it, for an IDE parsing it, etc.) in order to save a few characters. Bad trade-off. --Larry Garfield