Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50810 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31082 invoked from network); 2 Dec 2010 13:10:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Dec 2010 13:10:18 -0000 Authentication-Results: pb1.pair.com header.from=peter@lvp-media.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=peter@lvp-media.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lvp-media.com from 209.85.216.170 cause and error) X-PHP-List-Original-Sender: peter@lvp-media.com X-Host-Fingerprint: 209.85.216.170 mail-qy0-f170.google.com Received: from [209.85.216.170] ([209.85.216.170:62395] helo=mail-qy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A6/B8-15182-ABA97FC4 for ; Thu, 02 Dec 2010 08:10:18 -0500 Received: by qyk10 with SMTP id 10so3798713qyk.8 for ; Thu, 02 Dec 2010 05:10:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.19.130 with SMTP id a2mr47157qab.33.1291295415893; Thu, 02 Dec 2010 05:10:15 -0800 (PST) Received: by 10.220.19.200 with HTTP; Thu, 2 Dec 2010 05:10:15 -0800 (PST) In-Reply-To: References: <1290879624.7033.826.camel@guybrush> Date: Thu, 2 Dec 2010 14:10:15 +0100 Message-ID: To: Patrick ALLAERT Cc: =?ISO-8859-1?B?QW5kcukgUvhtY2tl?= , Kalle Sommer Nielsen , =?ISO-8859-1?Q?Johannes_Schl=FCter?= , PHP internals list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations From: peter@lvp-media.com (Peter Beverloo) On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT wrot= e: > 2010/12/2 Andr=E9 R=F8mcke : >> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT >> wrote: >>> Shouldn't we get rid of that kind of pre-PHP5 stuff _before_ >>> introducing the possible omission of T_FUNCTION? >> >> Why? >> This will break lots of code, does it improve anything while at it? Is '= var' >> hindering anything? Is it taking up a lot of code? >> If it is removed then that should be in trunk aka "6.0" the 2nd , and no= t in >> 5.x. > > It should of course not appear in a 5.x release! But sounds like > current trunk can't be anyway. > > +1 for removing T_VAR and making T_FUNCTION optional in a major release. > -1 otherwise. > > -- > Patrick Allaert > --- > http://code.google.com/p/peclapm/ - Alternative PHP Monitor > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. Regards, Peter Beverloo