Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74804
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
Message-ID: <5395DB90.40307@gmail.com>
Date: Mon, 09 Jun 2014 17:06:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c-jyBCnHdYjssGV+Avsw2B=Zt8TpNUzuDsNDWabV43fQg@mail.gmail.com> <5395CC8D.5060702@anderiasch.de>
In-Reply-To: <5395CC8D.5060702@anderiasch.de>
Content-Type: multipart/alternative;
 boundary="------------060502090102000607060905"
Subject: Re: [PHP-DEV] [RFC] [PHP 6] Uniform Variable Syntax
From: rowan.collins@gmail.com (Rowan Collins)

--------------060502090102000607060905
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Florian Anderiasch wrote (on 09/06/2014):
>> Foo::$bar['baz']()  Foo::{$bar['baz']}()  (Foo::$bar)['baz']()
>> >$foo->$bar['baz']() $foo->{$bar['baz']}() ($foo->$bar)['baz']()
> Those last 2 lines (old meaning) are exactly as I would have read them
> without thinking. So.. either I just got used to some kind of subliminal
> rule over all these years or I'm missing something.

I think it's somewhat subjective; it wouldn't have occurred to me that 
$foo->$bar['baz']() would evaluate $bar['baz'] rather than $foo->$bar. 
The advantage of the proposed behaviour is that it can be easily 
explained to *new* users of the language, as it's internally consistent, 
which appears not to be true of the old - an example in the RFC being 
|Foo::$bar[1][2][3] vs ||Foo::$bar[1][2][3]()|

The ability for any length of expression to be evaluated consistently 
and according to an easily-explained logic makes this RFC a massive win 
for me unless anyone can come up with a case it changes that would 
already be in common use.

If this had happened sooner, we wouldn't have needed separate RFCs for 
some_function()['array_key'] and (new Some_Class)->someMethod()

> They're not variable variables, either.

Technically, $foo->$bar is a "dynamic property access" (resolve the 
contents of $bar as a string, access that property), but it has a lot in 
common with what are commonly thought of as "variable variables"; if you 
have a class with property 'prop1', "normal" access would be via 
$foo->prop1, just as "normal" access to a variable would be $var1, not 
$$foo.

There are slightly more cases where dynamic property access makes sense 
than plain variable variables (which can nearly always be replaced with 
an associative array), but exotic combinations like the ones affected 
here seem unlikely to be commonplace.

Regards,
-- 
Rowan Collins
[IMSoP]

--------------060502090102000607060905--