Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50654
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Daniel Convissor <danielc@analysisandsolutions.com>
Cc: PHP Internals List <internals@lists.php.net>
In-Reply-To: <20101128140201.GA11105@panix.com>
References: <1290879624.7033.826.camel@guybrush>
	 <20101128014340.GA24343@panix.com>  <20101128140201.GA11105@panix.com>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 28 Nov 2010 15:29:39 +0100
Message-ID: <1290954580.22413.103.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method
 declarations
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Sun, 2010-11-28 at 09:02 -0500, Daniel Convissor wrote:
> Hi Again:
> 
> On Sat, Nov 27, 2010 at 08:43:40PM -0500, Daniel Convissor wrote:
> > 
> > Not that my vote really counts, but -1.  Doing so would eliminate the 
> > helpful ability to grep source code for 'function bar'.

I can see this point.

> It also will trip up the multitude of PHP IDE's and editors.  Plus it 
> reduces code portability.  All for saving us making a typo and having to 
> write "function"?

PHP IDE's don't understand traits per se, they don't understand other
changes per se. Code using new features won't work on older versions,
but there's a way to be compatible. Depending on your requirements and
likes.

johannes