# [RFC] 5.4 features for vote (long) - Thread: https://externals.io/message/53349 - Original archive: https://news-web.php.net/php.internals/53349 - Started by Stas Malyshev on 2011-06-16T22:08:31+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #53349 — Stas Malyshev — 2011-06-16T22:08:31+00:00 URL: https://externals.io/message/53349#53349 Hi! Below is the list of the features proposed for inclusion in 5.4, as outlined in https://wiki.php.net/todo/php54. Please read the TODO page and the RFCs linked there for details. This mail is not a vote call but rather description of things that will be put to vote soon. For each one, I'd like to see that: a. It is clear to everybody what is being proposed. If you have any doubts or see that it needs further discussion, please tell. b. We didn't miss something. If you have a proposal that has RFC in good shape, patch (or can have patch within 1 month from now) and you think has to be in 5.4 and has good chance for community support, please tell. c. For proposals that have assigned developers, I'd like for them to ensure they still want these proposals in and commit to doing the work in time for 5.4 beta (~end of July). It's no point to vote on a feature if the developer responsible for it won't have time or desire to implement it. If the proposal doesn't have anybody assigned, that means I can do it if needed - though of course I'd be glad if somebody else would do it too. So here goes the big list: 1. Declare PHP/php reserved namespace name, not to be used in any user code. Does not require any code change, only documentation changes. 2. Make primitive type names reserved words (in case we ever want some form of scalar typing or anything else with scalar types). Using them as identifiers would return parse error for now. May have BC implications. 3. Add `E_STRICT` to E_ALL. Nuff said. We did it in 6.0/unicode branch but didn't backport it. 4. Drop magic quotes. We've deprecated them in 5.3, we can kill them in 5.4. See the RFC for fine details. 5. Binary notation for ints (0b10101). Same as 0x, but in binary. Python has it, we could too :) 6. Array shortcuts. Make [ 'blah', 'blah' ] work same as array('blah', 'blah'), etc. Does not include any new JSON-like syntax, etc. - just making '[' be 'array(' and ']' be ')' in that context. 7. "Disable POST data processing" INI option. Assigned: Gustavo Lopes 8. Cli web server. Built-in mini-HTTP server run directly from PHP binary. Assigned: Moriyoshi Koizumi 9. Session Handlers class. A class that implements current session handler and can be extended with user code, fully or partially. Assigned: Arpad Ray 10. Callback type check in arguments. Type check in method calls same as 'array' or 'MyClass' type checks but would match valid callbacks. Assigned: Hannes Magnusson -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53384 — Moriyoshi Koizumi — 2011-06-20T11:31:22+00:00 URL: https://externals.io/message/53349#53384 · In reply to: #53349 Hi, I've been pretty busy for a while, and didn't well keep up to discussions regarding my built-in server patch. Is there any agreement on it yet? Moriyoshi > Hi! > > Below is the list of the features proposed for inclusion in 5.4, as outlined in https://wiki.php.net/todo/php54. Please read the TODO page and the RFCs linked there for details. > This mail is not a vote call but rather description of things that will be put to vote soon. For each one, I'd like to see that: > > a. It is clear to everybody what is being proposed. If you have any doubts or see that it needs further discussion, please tell. > > b. We didn't miss something. If you have a proposal that has RFC in good shape, patch (or can have patch within 1 month from now) and you think has to be in 5.4 and has good chance for community support, please tell. > > c. For proposals that have assigned developers, I'd like for them to ensure they still want these proposals in and commit to doing the work in time for 5.4 beta (~end of July). It's no point to vote on a feature if the developer responsible for it won't have time or desire to implement it. > If the proposal doesn't have anybody assigned, that means I can do it if needed - though of course I'd be glad if somebody else would do it too. > > So here goes the big list: > > 1. Declare PHP/php reserved namespace name, not to be used in any user code. Does not require any code change, only documentation changes. > > 2. Make primitive type names reserved words (in case we ever want some form of scalar typing or anything else with scalar types). Using them as identifiers would return parse error for now. May have BC implications. > > 3. Add `E_STRICT` to E_ALL. Nuff said. We did it in 6.0/unicode branch but didn't backport it. > > 4. Drop magic quotes. We've deprecated them in 5.3, we can kill them in 5.4. See the RFC for fine details. > > 5. Binary notation for ints (0b10101). Same as 0x, but in binary. Python has it, we could too :) > > 6. Array shortcuts. Make [ 'blah', 'blah' ] work same as array('blah', 'blah'), etc. Does not include any new JSON-like syntax, etc. - just making '[' be 'array(' and ']' be ')' in that context. > > 7. "Disable POST data processing" INI option. > Assigned: Gustavo Lopes > > 8. Cli web server. Built-in mini-HTTP server run directly from PHP binary. > Assigned: Moriyoshi Koizumi > > 9. Session Handlers class. A class that implements current session handler and can be extended with user code, fully or partially. > Assigned: Arpad Ray > > 10. Callback type check in arguments. Type check in method calls same as 'array' or 'MyClass' type checks but would match valid callbacks. > Assigned: Hannes Magnusson > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #53387 — Derick Rethans — 2011-06-20T11:39:42+00:00 URL: https://externals.io/message/53349#53387 · In reply to: #53349 > 3. Add `E_STRICT` to E_ALL. Nuff said. We did it in 6.0/unicode branch but > didn't backport it. Not sure about that. Can't we just tell people to use -1 ? > 6. Array shortcuts. Make [ 'blah', 'blah' ] work same as array('blah', > 'blah'), etc. Does not include any new JSON-like syntax, etc. - just making > '[' be 'array(' and ']' be ')' in that context. And for associative arrays only "=>" ? > 8. Cli web server. Built-in mini-HTTP server run directly from PHP binary. > Assigned: Moriyoshi Koizumi I'd really like to see that one. I thought the patch was already committed? Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #53399 — Moriyoshi Koizumi — 2011-06-20T12:38:20+00:00 URL: https://externals.io/message/53349#53399 · In reply to: #53387 > > […] > > I'd really like to see that one. I thought the patch was already > committed? Not yet. I'm gonna commit it in six hours or so if no one objects ;-) Moriyoshi > > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug --- ## #53410 — Etienne Kneuss — 2011-06-20T14:47:53+00:00 URL: https://externals.io/message/53349#53410 · In reply to: #53349 Hi, > Hi! > > Below is the list of the features proposed for inclusion in 5.4, as outlined > in https://wiki.php.net/todo/php54. Please read the TODO page and the RFCs > linked there for details. > This mail is not a vote call but rather description of things that will be > put to vote soon. For each one, I'd like to see that: > > a. It is clear to everybody what is being proposed. If you have any doubts > or see that it needs further discussion, please tell. > > b. We didn't miss something. If you have a proposal that has RFC in good > shape, patch (or can have patch within 1 month from now) and you think has > to be in 5.4 and has good chance for community support, please tell. I'd love to see the proposal from Felipe about the improved parse errors in that list. I believe that the patch was ready or almost ready? I can't find the RFC though, but maybe the RFC never existed... Best, -- Etienne Kneuss http://www.colder.ch --- ## #53418 — Felipe Pena — 2011-06-20T15:45:37+00:00 URL: https://externals.io/message/53349#53418 · In reply to: #53410 Hi, 2011/6/20 Etienne Kneuss > Hi, > > > On Fri, Jun 17, 2011 at 00:08, Stas Malyshev > wrote: > > […] > outlined > > […] > RFCs > > […] > be > > […] > doubts > > […] > has > > […] > > I'd love to see the proposal from Felipe about the improved parse > errors in that list. I believe that the patch was ready or almost > ready? I can't find the RFC though, but maybe the RFC never existed... > > Best, > https://wiki.php.net/rfc/improved-parser-error-message -- Regards, Felipe Pena --- ## #53420 — Derick Rethans — 2011-06-20T15:50:30+00:00 URL: https://externals.io/message/53349#53420 · In reply to: #53418 > 2011/6/20 Etienne Kneuss > > […] > > https://wiki.php.net/rfc/improved-parser-error-message I think this is good and helpful. I've two suggestions though: - Add the token name in parenthesis at the end of the string - Add '' around the token strings Examples: Parse error: syntax error, unexpected '<<=' (T_SL_EQUAL) in Command line code on line 1 Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in Command line code on line 1 Parse error: syntax error, unexpected 'quoted-string' (T_CONSTANT_ENCAPSED_STRING), expecting identifier or '(' in Command line code on line 1 And we need to make sure to check for escaped < and > in HTML error messages :) cheers, Derick --- ## #53429 — Stas Malyshev — 2011-06-20T16:51:05+00:00 URL: https://externals.io/message/53349#53429 · In reply to: #53387 Hi! > > > > […] > > Not sure about that. Can't we just tell people to use -1 ? Well, yes, but a) we had it in 6.0 and b) ALL not meaning "all" is weird. > > […] > > And for associative arrays only "=>" ? Yes. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53430 — Stas Malyshev — 2011-06-20T16:54:48+00:00 URL: https://externals.io/message/53349#53430 · In reply to: #53410 Hi! > I'd love to see the proposal from Felipe about the improved parse > errors in that list. I believe that the patch was ready or almost > ready? I can't find the RFC though, but maybe the RFC never existed... Thanks, missed it. I think based on the discussion and wide acceptance we could put it on the TODO. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53446 — Christopher Jones — 2011-06-20T19:29:24+00:00 URL: https://externals.io/message/53349#53446 · In reply to: #53420 > > > > […] > > I think this is good and helpful. > I've two suggestions though: > > - Add the token name in parenthesis at the end of the string > - Add '' around the token strings > > Examples: > Parse error: syntax error, unexpected '<<=' (T_SL_EQUAL) in Command line code on line 1 > Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in Command line code on line 1 > Parse error: syntax error, unexpected 'quoted-string' (T_CONSTANT_ENCAPSED_STRING), expecting identifier or '(' in Command line code on line 1 > > And we need to make sure to check for escaped< and> in HTML error > messages :) > > cheers, > Derick > Having the script token text is a good idea. If messages are changing, can we feasibly strip the Bison "syntax error, " component? The "Command line code" component is arguably useless too. Or at least it could be lower cased to "command line", though changing this in php_cli.c may have an unwanted cascading effect (?) An example message: Parse error: unexpected 'quoted-string' (T_CONSTANT_ENCAPSED_STRING), expecting identifier or '(' on line 1 Chris -- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ --- ## #53448 — Stas Malyshev — 2011-06-20T20:26:55+00:00 URL: https://externals.io/message/53349#53448 · In reply to: #53446 Hi! > If messages are changing, can we feasibly strip the Bison "syntax > error, " component? The "Command line code" component is arguably > useless too. Or at least it could be lower cased to "command line", > though changing this in php_cli.c may have an unwanted cascading > effect (?) I would assume "Command line code" comes from filename component of the metadata for the code being parsed. I guess it would be possible to detect when it's command-line and skip it, but what for? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53456 — Felipe Pena — 2011-06-21T03:09:37+00:00 URL: https://externals.io/message/53349#53456 · In reply to: #53420 2011/6/20 Derick Rethans > > > > > […] > > I think this is good and helpful. > I've two suggestions though: > > - Add the token name in parenthesis at the end of the string > - Add '' around the token strings > > Examples: >  Parse error: syntax error, unexpected '<<=' (T_SL_EQUAL) in Command line code on line 1 >  Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in Command line code on line 1 >  Parse error: syntax error, unexpected 'quoted-string' (T_CONSTANT_ENCAPSED_STRING), expecting identifier or '(' in Command line code on line 1 > To have the quoting message working as desired, we need to implement the yytnamerr function (based in the default one) e.g.: static YYSIZE_T zend_yytnamerr(char *yyres, const char *yystr) { if (!yyres) { return yystrlen(yystr); } if (*yystr == '"') { YYSIZE_T yyn = 0; char const *yyp = yystr; while (1) { if (*++yyp != '"') { yyres[yyn++] = *yyp; } else { yyres[yyn] = '\0'; return yyn; } } } return yystpcpy (yyres, yystr) - yyres; } I'm ok with this, I just think it's ugly to repeat the token name in the definition in the .y file. :P %token `T_LNUMBER` "'number' (T_LNUMBER)" %token `T_STRING` "'identifier' (T_STRING)" $ sapi/cli/php -r 'function 1' Parse error: syntax error, unexpected 'number' (T_LNUMBER), expecting 'identifier' (T_STRING) or '(' in Command line code on line 1 -- Regards, Felipe Pena --- ## #53457 — Rasmus Lerdorf — 2011-06-21T03:17:07+00:00 URL: https://externals.io/message/53349#53457 · In reply to: #53456 > I'm ok with this, I just think it's ugly to repeat the token name in > the definition in the .y file. :P > > %token `T_LNUMBER` "'number' (T_LNUMBER)" > %token `T_STRING` "'identifier' (T_STRING)" Why 'identifier' and not 'string' or 'string-literal' there? People know what a string is. I am not sure that people know what an identifier is, so in this case changing the error message from something that says "expecting T_STRING" to "expecting identifier" isn't making the error message any clearer as far as I am concerned. This is one of the reasons that having the token name there is useful. It provides continuity with the current error messages that people have grown used to. I think we either need the token names, or we need more descriptive names printed. -Rasmus --- ## #53464 — Etienne Kneuss — 2011-06-21T09:29:43+00:00 URL: https://externals.io/message/53349#53464 · In reply to: #53457 Hello, > > > > […] > > Why 'identifier' and not 'string' or 'string-literal' there? For people using php, a string or a string literal is "foo" or 'foo'. `T_STRING` does not represent "foo" nor 'foo'. identifier seems to adequatly describe what it encompass. IMHO, it would even be better if the unnexpect part displayed the actual content: i.e. function 1() => Unexpected number '1' ... or function 1() => Unexpected '1'... Best, > People know > what a string is. I am not sure that people know what an identifier is, > so in this case changing the error message from something that says > "expecting T_STRING" to "expecting identifier" isn't making the error > message any clearer as far as I am concerned. This is one of the reasons > that having the token name there is useful. It provides continuity with > the current error messages that people have grown used to. I think we > either need the token names, or we need more descriptive names printed. > > -Rasmus > -- Etienne Kneuss http://www.colder.ch --- ## #53476 — Felipe Pena — 2011-06-21T11:13:39+00:00 URL: https://externals.io/message/53349#53476 · In reply to: #53464 2011/6/21 Etienne Kneuss : > Hello, > > > > […] > > For people using php, a string or a string literal is "foo" or 'foo'. > `T_STRING` does not represent "foo" nor 'foo'. > identifier seems to adequatly describe what it encompass. > > IMHO, it would even be better if the unnexpect part displayed the > actual content: > > i.e. > > function 1() => Unexpected number '1' ... > or > function 1() => Unexpected '1'... > Currently it's possible to do this, it'll only require a static variable in yytnamerr implementation. -- Regards, Felipe Pena