Re: RFC: Making T_FUNCTION optional in method declarations
| From: | Johannes Schlüter | Date: | Sat, 27 Nov 2010 22:14:34 +0000 |
| Subject: | Re: RFC: Making T_FUNCTION optional in method declarations | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-50643@lists.php.net to get a copy of this message | ||
On Sat, 2010-11-27 at 22:58 +0100, Mike Van Riel wrote:
> With this patch I will loose this recognition point and the first
> solution that comes to mind is to search for () or arguments. This
> sounds rather hackish to me, might I be missing a solution?
The rule is something like
[ T_PUBLIC | T_PROTECTED | T_PRIVATE | T_STATIC | T_ABSTRACT ] { & } T_STRING "("
param_list ")" { "{" statement_ist "}" }
Where [] marks a choice of one or more and {} something optional.
I think you could detect this similar to the way you're dealing with
properties. If the T_STRING after the visibility modifier begins with a
"$" it is a property, else it is a method. If the visibility modifier is
followed by a "&" it is a method returning a reference.
> Another question is: when would you like to have this released? PHP-
> next? (thus either 5.4, 6, 7 or whichever is next?).
I'd like it asap. But let's see where the version discussions go, I
think this should be grouped together with Felipe's direct dereferencing
of new objects etc.
johannes