Re: [RFC] [PHP 6] Uniform Variable Syntax
| From: | Rowan Collins | Date: | Mon, 09 Jun 2014 16:06:40 +0000 |
| Subject: | Re: [RFC] [PHP 6] Uniform Variable Syntax | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-74804@lists.php.net to get a copy of this message | ||
Florian Anderiasch wrote (on 09/06/2014):
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()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.
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]