Hi internals!
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:
https://wiki.php.net/rfc/uniform_variable_syntax
The RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.
Thanks,
Nikita
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:https://wiki.php.net/rfc/uniform_variable_syntax
The RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.
I love this proposal! The behaviour of $$ is non-intuitive at present and has bitten me more than once, and the weird behaviour of :: has also caused me problems. In particular, my miniature web framework didn’t work properly due to this line:
self::$views[$path]();
It’s easy to fix ($x = self::$views[$path]; $x();) but the fact that didn’t work has bothered me immensely for two years. It seems to me like the RFC would fix this. Would it? If so, you are my hero.
On a somewhat more serious note, do we have any idea of how much code this would break? Is the current behaviour widely relied-upon?
--
Andrea Faulds
http://ajf.me/
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:https://wiki.php.net/rfc/uniform_variable_syntax
The RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.I love this proposal! The behaviour of $$ is non-intuitive at present and
has bitten me more than once, and the weird behaviour of :: has also caused
me problems. In particular, my miniature web framework didn’t work properly
due to this line:self::$views[$path]();It’s easy to fix ($x = self::$views[$path]; $x();) but the fact that
didn’t work has bothered me immensely for two years. It seems to me like
the RFC would fix this. Would it? If so, you are my hero.
Yes, it would ;)
On a somewhat more serious note, do we have any idea of how much code this
would break? Is the current behaviour widely relied-upon?
Quoting
https://wiki.php.net/rfc/uniform_variable_syntax#backward_incompatible_changes
:
An analysis of the Zend Framework and Symfony projects
(including standard dependencies) showed that only a single
occurrence of $loader[0]::$loader1 in the Doctrine
class loader will be affected by this change.
So I think that this will not break much code. It is also easy to detect
and fix. (I am using this script to find potential problems:
https://gist.github.com/nikic/ffd019ef78b72934c7cc)
Nikita
So I think that this will not break much code. It is also easy to detect
and fix. (I am using this script to find potential problems:
https://gist.github.com/nikic/ffd019ef78b72934c7cc)
I like that you have a script. Myself, I’d like to see more of these. Since your PhpParser exists, if we make some major syntax change in PHP6, it might be possible to write a tool that would (semi-)automatically re-write code, similar to what Python’s 2to3 tool does.
--
Andrea Faulds
http://ajf.me/
https://wiki.php.net/rfc/uniform_variable_syntaxThe RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.
I am all for consistency, but if I look at this:
Example of expressions those meaning changes:
// old meaning // new meaning$$foo['bar']['baz'] ${$foo['bar']['baz']} ($$foo)['bar']['baz']
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.
Somewhere in the proposal you write "It follows normal left-to-right
semantic". This sounds very good in theory, but right now it feels a
little unintuitive.
Greetings,
Florian
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]
Rowan Collins wrote (on 09/06/2014):
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|
A simpler example of the current logic's inconsistencies:
$foo = 'foo';
$bar->$foo = array();
$bar->$foo[0] = 42;
// $bar now has an array on ->foo, and an integer on ->f
Not only does this not feel consistent in itself, it's different if you
do the same thing with an object:
$foo = 'foo';
$bar->$foo = new stdClass;
$bar->$foo->x = 42;
// $bar now has a single property ->foo, which is an object with
property ->x
Other than "it's always worked this way", I can't think of a good
justification for this difference.
--
Rowan Collins
[IMSoP]
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:https://wiki.php.net/rfc/uniform_variable_syntaxThe RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.
I like it.
A Monday morning, pre-caffeine-kicking-in thought (so it may not be
very worthwhile): can we detect the situations that would change with
this patch applied within the current parser? If we did go ahead with
this for PHP 5++, then we could potentially add E_STRICT warnings in
PHP 5.7 notifying users that the behaviour will change in the next
major version.
Adam
Hi internals!
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:
Thank you!
Hi internals!
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:https://wiki.php.net/rfc/uniform_variable_syntaxThe RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.Thanks,
Nikita
Nice proposal :-)
Julien
hi Nikita,
Hi internals!
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:https://wiki.php.net/rfc/uniform_variable_syntaxThe RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.
Very good RFC. Long due and php6 is really the right time to do it. As
you said it should have a minimal impact on existing code.
If accepted, it would be a good thing to add notices in 5.6 as well,
if it does not impact performance too much.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi!
If accepted, it would be a good thing to add notices in 5.6 as well,
if it does not impact performance too much.
I wouldn't be that fast with it, since notices are very expensive
(compared to regular opcodes), and disabling them via error_level does
nothing to mitigate that effect, and may easily lead to breakage in
systems which have custom handlers - like unit tests, monitoring, etc.
When we're going to 6, it's good to break things we want to change. When
we're talking about 5.6, less disruption to existing working code the
better.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi internals!
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:https://wiki.php.net/rfc/uniform_variable_syntaxThe RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.
Any more feedback on this? Otherwise I'll start the vote sometime soon :)
Nikita
2014-07-02 17:51 GMT+02:00 Nikita Popov nikita.ppv@gmail.com:
Hi internals!
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:https://wiki.php.net/rfc/uniform_variable_syntaxThe RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.Any more feedback on this? Otherwise I'll start the vote sometime soon :)
Yes, in the RFC, you mention that this will be possible:
($obj->closure)()
While this is very welcome, I was wandering if we could skip the extra
parenthesis, like this:
$obj->closure()
Likewise, this would also be nice:
new ClassName->foo()
Thanks,
Lazare INEPOLOGLOU
Ingénieur Logiciel
Yes, in the RFC, you mention that this will be possible:
($obj->closure)()
While this is very welcome, I was wandering if we could skip the extra
parenthesis, like this:$obj->closure()
Sadly, it wouldn’t be possible as the two are very different. Properties and methods occupy completely different namespaces, and while methods are case-insentivie, properties are case-sensitive! ($obj->closure)() gets a property then calls it, while $obj->closure() calls a method.
Perhaps this might change in future, but the RFC doesn’t propose that.
Andrea Faulds
http://ajf.me/
On Wed, Jul 2, 2014 at 6:04 PM, Lazare Inepologlou linepogl@gmail.com
wrote:
2014-07-02 17:51 GMT+02:00 Nikita Popov nikita.ppv@gmail.com:
Hi internals!
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:https://wiki.php.net/rfc/uniform_variable_syntaxThe RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.Any more feedback on this? Otherwise I'll start the vote sometime soon :)
Yes, in the RFC, you mention that this will be possible:
($obj->closure)()
While this is very welcome, I was wandering if we could skip the extra
parenthesis, like this:$obj->closure()
We could skip the extra parenthesis, but that would require changing the
meaning of method calls. This discussion turns up every now and then, one
of the more recent ones being http://markmail.org/message/3zi53txadno6xrqa.
A key problem was always that supporting this would break BC. However that
BC break may be acceptable for PHP 6, so the it might be worthwhile to
reconsider the previous decisions regarding this issue.
However this is not related to variable syntax (it is a question of method
lookup semantics), so I would suggest opening a new discussion thread for
this (and/or write an RFC for it).
Likewise, this would also be nice:
new ClassName->foo()
This is problematic because the following would be ambiguous:
new $className->foo()
// could be (_current_ behavior)
new ($className->foo)()
// or
(new $className)->foo()
Of course we could resolve the ambiguity (towards the latter
interpretation) or special-case the plain-classname case. Both options do
not seem very appealing to me. Imho it's better to keep the explicit syntax.
Nikita
How would you create a new callable object and then invoke it? Since
'nested' () is now supported:
new MagicInvoke()();
Could be the same as:
(new MagicInvoke())();
On Wed, Jul 2, 2014 at 6:04 PM, Lazare Inepologlou linepogl@gmail.com
wrote:2014-07-02 17:51 GMT+02:00 Nikita Popov nikita.ppv@gmail.com:
On Mon, Jun 9, 2014 at 3:33 PM, Nikita Popov nikita.ppv@gmail.com
wrote:Hi internals!
I have created a proposal for a more consistent and complete variable
syntax for PHP 6:https://wiki.php.net/rfc/uniform_variable_syntaxThe RFC is targeted at PHP 6 because it breaks compatibility for some
rarely used variable-variable constructs.Any more feedback on this? Otherwise I'll start the vote sometime soon
:)Yes, in the RFC, you mention that this will be possible:
($obj->closure)()
While this is very welcome, I was wandering if we could skip the extra
parenthesis, like this:$obj->closure()
We could skip the extra parenthesis, but that would require changing the
meaning of method calls. This discussion turns up every now and then, one
of the more recent ones being http://markmail.org/message/3zi53txadno6xrqa
.
A key problem was always that supporting this would break BC. However that
BC break may be acceptable for PHP 6, so the it might be worthwhile to
reconsider the previous decisions regarding this issue.However this is not related to variable syntax (it is a question of method
lookup semantics), so I would suggest opening a new discussion thread for
this (and/or write an RFC for it).Likewise, this would also be nice:
new ClassName->foo()
This is problematic because the following would be ambiguous:
new $className->foo() // could be (_current_ behavior) new ($className->foo)() // or (new $className)->foo()Of course we could resolve the ambiguity (towards the latter
interpretation) or special-case the plain-classname case. Both options do
not seem very appealing to me. Imho it's better to keep the explicit
syntax.Nikita
Hi!
While this is very welcome, I was wandering if we could skip the extra
parenthesis, like this:$obj->closure()
The would mean uniting the property and method namespaces on an object,
which has pretty big implications and may lead to huge BC issues. I'd
rather not go there, it'd require serious change of the whole object model.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/