Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62747
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 64.22.89.134 as permitted sender)
Message-ID: <5044CA5C.9080208@ajf.me>
Date: Mon, 03 Sep 2012 16:18:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: ivan.enderlin@hoa-project.net
CC: internals@lists.php.net
References: <5044C3E6.8040202@hoa-project.net>
In-Reply-To: <5044C3E6.8040202@hoa-project.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] $obj->attr::method() is not allowed
From: ajf@ajf.me (Andrew Faulds)

On 03/09/12 15:51, Ivan Enderlin @ Hoa wrote:
>
> I would like to know why? Is it a compiler related issue or just an 
> omission? Would it be interesting to fix it?
>
There are plenty of examples of this. One from my code:

Can't do this:

     self::$views[$path]();

But I *can* do this:

     $x = self::$views[$path]; $x();

This is because PHP has a very unusual (and IMO bad) system of 
type-checking at parse-time, by only allowing some specific (although 
quite varied) types of variable access, and combinations of these.

If nikic's idea to rewrite the parser to use an AST is done, I imagine 
this could be fixed. We could also add extra rules, but I think fixing 
the general issue is more important, since it's like plugging two holes 
in a barrel full of water that's just had a machine gun fired at it.

-- 
Andrew Faulds
http://ajf.me/