Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE] Uniform Variable Syntax »

[VOTE] Uniform Variable Syntax

php.internals

Nikita Popov

12 years ago
Hi internals! I've started the vote on the Uniform Variable Syntax RFC: https://wiki.php.net/rfc/uniform_variable_syntax#vote You can review the discussion about this RFC here: http://markmail.org/message/mr4ihbubfbdxygci The vote requires a 2/3 majority and is planned to end on 2014-07-14. The RFC targets PHP 6. Thanks, Nikita

Laruence

12 years ago
Hey: On Mon, Jul 7, 2014 at 10:18 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hi internals! > > I've started the vote on the Uniform Variable Syntax RFC: > > https://wiki.php.net/rfc/uniform_variable_syntax#vote > > You can review the discussion about this RFC here: > > http://markmail.org/message/mr4ihbubfbdxygci > > The vote requires a 2/3 majority and is planned to end on 2014-07-14. The > RFC targets PHP 6.
sorry for didn't read the RFC before, but I can not vote for yes.. here are some words in RFC: 1. "The current patch introduces a new “write context” issue. Namely ($foo)['bar'] = 'baz' will not behave this same was as $foo['bar'] = 'baz'. In the former case an undefined variable notice will be thrown if $foo does not exist, whereas the latter does not throw a notice." 2. "As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 6." I don't think we should introduce a new thing which is not perfect or "confused".. it looks like we fixed a mess with a new mess. it make me think we should : "don't fix it until it is broken" thanks
> > Thanks, > Nikita
-- Laruence Xinchen Hui http://www.laruence.com/

Andrew Faulds

12 years ago
On 7 Jul 2014, at 15:42, Laruence <laruence@php.net> wrote:
> 1. "The current patch introduces a new “write context” issue. Namely > ($foo)['bar'] = 'baz' will not behave this same was as $foo['bar'] = > 'baz'. In the former case an undefined variable notice will be thrown > if $foo does not exist, whereas the latter does not throw a notice." > > 2. "As these changes only apply to some very rarely used syntax, the > breakage seems acceptable for PHP 6." > > > I don't think we should introduce a new thing which is not perfect or > "confused".. it looks like we fixed a mess with a new mess. > > it make me think we should : "don't fix it until it is broken”
We are fixing what is broken here; the variable syntax is counter-intuitive at the moment, and they make the syntax more consistent overall. Also, parentheses in PHP are always a source of issues. I don’t think they’ll ever quite work properly unless we switch to using an AST-based parser someday.
-- Andrea Faulds http://ajf.me/

Laruence

12 years ago
On Mon, Jul 7, 2014 at 10:46 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > On 7 Jul 2014, at 15:42, Laruence <laruence@php.net> wrote: > >> 1. "The current patch introduces a new “write context” issue. Namely >> ($foo)['bar'] = 'baz' will not behave this same was as $foo['bar'] = >> 'baz'. In the former case an undefined variable notice will be thrown >> if $foo does not exist, whereas the latter does not throw a notice." >> >> 2. "As these changes only apply to some very rarely used syntax, the >> breakage seems acceptable for PHP 6." >> >> >> I don't think we should introduce a new thing which is not perfect or >> "confused".. it looks like we fixed a mess with a new mess. >> >> it make me think we should : "don't fix it until it is broken” > > We are fixing what is broken here; the variable syntax is counter-intuitive at the moment, and they make the syntax more consistent overall. > > Also, parentheses in PHP are always a source of issues. I don’t think they’ll ever quite work properly unless we switch to using an AST-based parser someday.
then we won't need to temporarily fix it.. anyway, it's just my 2 cents thanks
> -- > Andrea Faulds > http://ajf.me/ > > > >
-- Laruence Xinchen Hui http://www.laruence.com/

Ivan Enderlin @ Hoa

12 years ago
On 07/07/2014 16:54, Laruence wrote:
> On Mon, Jul 7, 2014 at 10:46 PM, Andrea Faulds <ajf@ajf.me> wrote: >> On 7 Jul 2014, at 15:42, Laruence <laruence@php.net> wrote: >> >>> 1. "The current patch introduces a new “write context” issue. Namely >>> ($foo)['bar'] = 'baz' will not behave this same was as $foo['bar'] = >>> 'baz'. In the former case an undefined variable notice will be thrown >>> if $foo does not exist, whereas the latter does not throw a notice." >>> >>> 2. "As these changes only apply to some very rarely used syntax, the >>> breakage seems acceptable for PHP 6." >>> >>> >>> I don't think we should introduce a new thing which is not perfect or >>> "confused".. it looks like we fixed a mess with a new mess. >>> >>> it make me think we should : "don't fix it until it is broken” >> We are fixing what is broken here; the variable syntax is counter-intuitive at the moment, and they make the syntax more consistent overall. >> >> Also, parentheses in PHP are always a source of issues. I don’t think they’ll ever quite work properly unless we switch to using an AST-based parser someday. > then we won't need to temporarily fix it.. > > anyway, it's just my 2 cents
While I deeply agree with you (introducing something we will need to fix later is not a good idea), this RFC fixes a lot of real, concrete and immediate issues that are blocking for the emergence of new tools (for example, a grammar of PHP that can be used by AST-compliant tools). Moreover, it defines a clear base for the semantics of variables. Known issues are well-spotted and define the very next steps of the work. Parentheses are interpreted in various ways according to the language and the area. Thus, a lot of (smart and calm) discussions will be required. However, this RFC is targeting PHP6 (and not 7… just kidding… or not… o_O), so we have time to fix the next spotted issues before the final release. Let's cut the giant task into small ones. I think this is the approach of Nikita since he has honestly exposed the known issues. Cheers :-).
-- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/

Laruence

12 years ago
Hey: On Mon, Jul 7, 2014 at 10:46 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > On 7 Jul 2014, at 15:42, Laruence <laruence@php.net> wrote: > >> 1. "The current patch introduces a new “write context” issue. Namely >> ($foo)['bar'] = 'baz' will not behave this same was as $foo['bar'] = >> 'baz'. In the former case an undefined variable notice will be thrown >> if $foo does not exist, whereas the latter does not throw a notice." >> >> 2. "As these changes only apply to some very rarely used syntax, the >> breakage seems acceptable for PHP 6." >> >> >> I don't think we should introduce a new thing which is not perfect or >> "confused".. it looks like we fixed a mess with a new mess. >> >> it make me think we should : "don't fix it until it is broken” > > We are fixing what is broken here; the variable syntax is counter-intuitive at the moment, and they make the syntax more consistent overall. > > Also, parentheses in PHP are always a source of issues. I don’t think they’ll ever quite work properly unless we switch to using an AST-based parser someday.
I've change my opinion..... I will vote for yes... thanks
> -- > Andrea Faulds > http://ajf.me/ > > > >
-- Laruence Xinchen Hui http://www.laruence.com/

Ferenc Kovacs

12 years ago
On Mon, Jul 7, 2014 at 4:18 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hi internals! > > I've started the vote on the Uniform Variable Syntax RFC: > > https://wiki.php.net/rfc/uniform_variable_syntax#vote > > You can review the discussion about this RFC here: > > http://markmail.org/message/mr4ihbubfbdxygci > > The vote requires a 2/3 majority and is planned to end on 2014-07-14. The > RFC targets PHP 6. > > Thanks, > Nikita >
Hi, just a small note, there is an empty todo block which probably should be removed: https://wiki.php.net/rfc/uniform_variable_syntax#todo
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Derick Rethans

12 years ago
On Mon, 7 Jul 2014, Nikita Popov wrote:
> Hi internals! > > I've started the vote on the Uniform Variable Syntax RFC: > > https://wiki.php.net/rfc/uniform_variable_syntax#vote > > You can review the discussion about this RFC here: > > http://markmail.org/message/mr4ihbubfbdxygci > > The vote requires a 2/3 majority and is planned to end on 2014-07-14. The > RFC targets PHP 6.
I've just voted "no" for this, because it introduces a tiny BC break. Now, I realize this is a tiny BC break, but it is just *those* that drive people nuts when upgrading. There is so much non-public code - a cursor check of Symfony and ZF is not representative. cheers, Derick

Andrew Faulds

12 years ago
On 8 Jul 2014, at 15:48, Derick Rethans <derick@php.net> wrote:
> I've just voted "no" for this, because it introduces a tiny BC break. > Now, I realize this is a tiny BC break, but it is just *those* that > drive people nuts when upgrading. There is so much non-public code - a > cursor check of Symfony and ZF is not representative.
It is a tiny BC break and it’s for PHP NEXT (i.e 6 or 7), not 5.6. Why not? It’s a tiny change which will bother some people but make everyone else’s life easier.
-- Andrea Faulds http://ajf.me/

Pierre Joye

12 years ago
On Tue, Jul 8, 2014 at 4:51 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > On 8 Jul 2014, at 15:48, Derick Rethans <derick@php.net> wrote: > >> I've just voted "no" for this, because it introduces a tiny BC break. >> Now, I realize this is a tiny BC break, but it is just *those* that >> drive people nuts when upgrading. There is so much non-public code - a >> cursor check of Symfony and ZF is not representative. > > It is a tiny BC break and it’s for PHP NEXT (i.e 6 or 7), not 5.6. Why not? It’s a tiny change which will bother some people but make everyone else’s life easier.
Voted +1, obviously for having that in php6, not 5.7. This tiny BC is then more than OK. Cheers,
-- Pierre @pierrejoye | http://www.libgd.org

Kris Craig

12 years ago
On Tue, Jul 8, 2014 at 9:48 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Tue, Jul 8, 2014 at 4:51 PM, Andrea Faulds <ajf@ajf.me> wrote: > > > > On 8 Jul 2014, at 15:48, Derick Rethans <derick@php.net> wrote: > > > >> I've just voted "no" for this, because it introduces a tiny BC break. > >> Now, I realize this is a tiny BC break, but it is just *those* that > >> drive people nuts when upgrading. There is so much non-public code - a > >> cursor check of Symfony and ZF is not representative. > > > > It is a tiny BC break and it’s for PHP NEXT (i.e 6 or 7), not 5.6. Why > not? It’s a tiny change which will bother some people but make everyone > else’s life easier. > > Voted +1, obviously for having that in php6, not 5.7. This tiny BC is > then more than OK. > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Also +1. Major version increments always have BC breaks, and not just tiny ones, either. --Kris

Julien Pauli

12 years ago
On Wed, Jul 9, 2014 at 1:06 AM, Kris Craig <kris.craig@gmail.com> wrote:
> On Tue, Jul 8, 2014 at 9:48 AM, Pierre Joye <pierre.php@gmail.com> wrote: > >> On Tue, Jul 8, 2014 at 4:51 PM, Andrea Faulds <ajf@ajf.me> wrote: >> > >> > On 8 Jul 2014, at 15:48, Derick Rethans <derick@php.net> wrote: >> > >> >> I've just voted "no" for this, because it introduces a tiny BC break. >> >> Now, I realize this is a tiny BC break, but it is just *those* that >> >> drive people nuts when upgrading. There is so much non-public code - a >> >> cursor check of Symfony and ZF is not representative. >> > >> > It is a tiny BC break and it’s for PHP NEXT (i.e 6 or 7), not 5.6. Why >> not? It’s a tiny change which will bother some people but make everyone >> else’s life easier. >> >> Voted +1, obviously for having that in php6, not 5.7. This tiny BC is >> then more than OK. >> >> Cheers, >> -- >> Pierre >> >> @pierrejoye | http://www.libgd.org >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > Also +1. Major version increments always have BC breaks, and not just tiny > ones, either.
+1 as well. For a next major, every tip making things cleaner is welcome, and this is little BC. Julien

Nikita Popov

12 years ago
On Mon, Jul 7, 2014 at 4:18 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hi internals! > > I've started the vote on the Uniform Variable Syntax RFC: > > https://wiki.php.net/rfc/uniform_variable_syntax#vote > > You can review the discussion about this RFC here: > > http://markmail.org/message/mr4ihbubfbdxygci > > The vote requires a 2/3 majority and is planned to end on 2014-07-14. The > RFC targets PHP 6. >
The vote closed with 30 in favor and 1 against, as such the RFC is accepted. I will delay merging the patch until the situation regarding phpng and PHP 6 is more clear. Thanks, Nikita

Ferenc Kovacs

12 years ago
On Mon, Jul 14, 2014 at 6:35 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Mon, Jul 7, 2014 at 4:18 PM, Nikita Popov <nikita.ppv@gmail.com> wrote: > > > Hi internals! > > > > I've started the vote on the Uniform Variable Syntax RFC: > > > > https://wiki.php.net/rfc/uniform_variable_syntax#vote > > > > You can review the discussion about this RFC here: > > > > http://markmail.org/message/mr4ihbubfbdxygci > > > > The vote requires a 2/3 majority and is planned to end on 2014-07-14. The > > RFC targets PHP 6. > > > > The vote closed with 30 in favor and 1 against, as such the RFC is > accepted. > > I will delay merging the patch until the situation regarding phpng and PHP > 6 is more clear. > > Thanks, > Nikita >
Hi Nikita, Derick mentioned in his blogpost( http://derickrethans.nl/uniform-variable-syntax.html) that "You can't really write a scanner for it, as the code could already have been converted.". I know that you posted https://gist.github.com/nikic/ffd019ef78b72934c7cc which uses PhpParser\Lexer from your PHP-Parser project, so my understanding was that it is possible to detect those expressions with both the current php stable version and with the new one containing the uniform_variable_syntax changes.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Andrew Faulds

12 years ago
On 22 Jul 2014, at 13:38, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> Derick mentioned in his blogpost( > http://derickrethans.nl/uniform-variable-syntax.html) that "You can't > really write a scanner for it, as the code could already have been > converted.”.
Of course what he said was true, but I’m not sure it’s important. If you scan your code before converting, or you revert to where you were prior to conversion (any project with proper version control should be able to do this) and then scan it, it’s going to work.
-- Andrea Faulds http://ajf.me/

Jannik Zschiesche

12 years ago
Hi Ferenc,
> On 22.07.2014, at 14:38, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > On Mon, Jul 14, 2014 at 6:35 PM, Nikita Popov <nikita.ppv@gmail.com> wrote: > >> On Mon, Jul 7, 2014 at 4:18 PM, Nikita Popov <nikita.ppv@gmail.com> wrote: >> >>> Hi internals! >>> >>> I've started the vote on the Uniform Variable Syntax RFC: >>> >>> https://wiki.php.net/rfc/uniform_variable_syntax#vote >>> >>> You can review the discussion about this RFC here: >>> >>> http://markmail.org/message/mr4ihbubfbdxygci >>> >>> The vote requires a 2/3 majority and is planned to end on 2014-07-14. The >>> RFC targets PHP 6. >>> >> >> The vote closed with 30 in favor and 1 against, as such the RFC is >> accepted. >> >> I will delay merging the patch until the situation regarding phpng and PHP >> 6 is more clear. >> >> Thanks, >> Nikita >> > > Hi Nikita, > > Derick mentioned in his blogpost( > http://derickrethans.nl/uniform-variable-syntax.html) that "You can't > really write a scanner for it, as the code could already have been > converted.". > I know that you posted https://gist.github.com/nikic/ffd019ef78b72934c7cc > which uses PhpParser\Lexer from your PHP-Parser project, so my > understanding was that it is possible to detect those expressions with both > the current php stable version and with the new one containing the > uniform_variable_syntax changes.
the point Derick was trying to make is that you can’t build a scanner that automatically checks whether you rewrote this particular piece of code already or not. You can find the code pieces which match the constructs affected by the BC, but the scanner can’t decide, whether they are already fixed (= they are ok as they stand). Which makes the burden of the update smaller, but you still need to check every match yourself, whether it will (still) work. (at least I read it like this) Cheers Jannik

Rowan Collins

12 years ago
Jannik Zschiesche wrote (on 22/07/2014):
> the point Derick was trying to make is that you can’t build a scanner that automatically checks whether you rewrote this particular piece of code already or not. > You can find the code pieces which match the constructs affected by the BC, but the scanner can’t decide, whether they are already fixed (= they are ok as they stand).
I thought for each ambiguous case whose behaviour would change, there is a pair of unambiguous forms (one for each interpretation) which work the same under both parsers? If so, wouldn't it be possible to change every occurrence detected by the scanner to the appropriate unambiguous form (even if that is technically unnecessary for that particular case); then when you re-ran the scanner, it wouldn't find the same ones again? I'm probably missing a subtlety here, though...
-- Rowan Collins [IMSoP]

Andrew Faulds

12 years ago
On 22 Jul 2014, at 14:47, Rowan Collins <rowan.collins@gmail.com> wrote:
> I thought for each ambiguous case whose behaviour would change, there is a pair of unambiguous forms (one for each interpretation) which work the same under both parsers?
That’s correct. For projects you want to run on both PHP 5 and PHP 6, this could be done.
-- Andrea Faulds http://ajf.me/