Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50826 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74941 invoked from network); 2 Dec 2010 16:10:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Dec 2010 16:10:42 -0000 Authentication-Results: pb1.pair.com smtp.mail=peter@lvp-media.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=peter@lvp-media.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lvp-media.com from 209.85.216.42 cause and error) X-PHP-List-Original-Sender: peter@lvp-media.com X-Host-Fingerprint: 209.85.216.42 mail-qw0-f42.google.com Received: from [209.85.216.42] ([209.85.216.42:51228] helo=mail-qw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 37/50-07252-005C7FC4 for ; Thu, 02 Dec 2010 11:10:41 -0500 Received: by qwj8 with SMTP id 8so4075168qwj.29 for ; Thu, 02 Dec 2010 08:10:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.96.136 with SMTP id h8mr175846qcn.184.1291306238254; Thu, 02 Dec 2010 08:10:38 -0800 (PST) Received: by 10.220.19.200 with HTTP; Thu, 2 Dec 2010 08:10:37 -0800 (PST) In-Reply-To: <4CF7C458.7040306@garfieldtech.com> References: <1290879624.7033.826.camel@guybrush> <4CF7C458.7040306@garfieldtech.com> Date: Thu, 2 Dec 2010 17:10:37 +0100 Message-ID: To: "larry@garfieldtech.com" Cc: internals@lists.php.net 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 17:07, larry@garfieldtech.com wrote: > On 12/2/10 7:51 AM, Patrick ALLAERT wrote: > >>>> +1 for removing T_VAR and making T_FUNCTION optional in a major releas= e. >>>> -1 otherwise. > > I am still firmly -1 on removing T_FUNCTION for methods. > >>>> -- >>>> 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. >> >> If people migrate to a major version of PHP> =A05 they should at least >> stop relying on PHP 4 features still valid thanks to BC consideration. >> >>> In either case, it should be >>> deprecated with an E_DEPRECATED warning during at least another major >>> before it gets removed. >> >> This makes much sense! > > Correct me if I'm wrong, but isn't T_VAR on class members already an > E_STRICT warning? =A0I thought it was... > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > No, the warning was removed in PHP 5.1.3. Regards, Peter Beverloo