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:
-
Declare PHP/php reserved namespace name, not to be used in any user
code. Does not require any code change, only documentation changes. -
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. -
Add
E_STRICTto E_ALL. Nuff said. We did it in 6.0/unicode branch but
didn't backport it. -
Drop magic quotes. We've deprecated them in 5.3, we can kill them in
5.4. See the RFC for fine details. -
Binary notation for ints (0b10101). Same as 0x, but in binary. Python
has it, we could too :) -
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. -
"Disable POST data processing" INI option.
Assigned: Gustavo Lopes -
Cli web server. Built-in mini-HTTP server run directly from PHP binary.
Assigned: Moriyoshi Koizumi -
Session Handlers class. A class that implements current session
handler and can be extended with user code, fully or partially.
Assigned: Arpad Ray -
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
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:
Declare PHP/php reserved namespace name, not to be used in any user code. Does not require any code change, only documentation changes.
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.
Add
E_STRICTto E_ALL. Nuff said. We did it in 6.0/unicode branch but didn't backport it.Drop magic quotes. We've deprecated them in 5.3, we can kill them in 5.4. See the RFC for fine details.
Binary notation for ints (0b10101). Same as 0x, but in binary. Python has it, we could too :)
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.
"Disable POST data processing" INI option.
Assigned: Gustavo LopesCli web server. Built-in mini-HTTP server run directly from PHP binary.
Assigned: Moriyoshi KoizumiSession Handlers class. A class that implements current session handler and can be extended with user code, fully or partially.
Assigned: Arpad RayCallback 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
- Add
E_STRICTto 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 ?
- 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 "=>" ?
- 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
- Cli web server. Built-in mini-HTTP server run directly from PHP binary.
Assigned: Moriyoshi KoizumiI'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
Hi!
- Add
E_STRICTto 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 ?
Well, yes, but a) we had it in 6.0 and b) ALL not meaning "all" is weird.
- 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 "=>" ?
Yes.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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
Hi,
2011/6/20 Etienne Kneuss colder@php.net
Hi,
On Fri, Jun 17, 2011 at 00:08, Stas Malyshev smalyshev@sugarcrm.com
wrote: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,
https://wiki.php.net/rfc/improved-parser-error-message
--
Regards,
Felipe Pena
2011/6/20 Etienne Kneuss colder@php.net
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...
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
2011/6/20 Etienne Kneusscolder@php.net
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...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 1And 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/
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
2011/6/20 Derick Rethans derick@php.net
2011/6/20 Etienne Kneuss colder@php.net
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...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
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)"
%tokenT_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
Hello,
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)"
%tokenT_STRING"'identifier' (T_STRING)"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
2011/6/21 Etienne Kneuss colder@php.net:
Hello,
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)"
%tokenT_STRING"'identifier' (T_STRING)"Why 'identifier' and not 'string' or 'string-literal' there?
For people using php, a string or a string literal is "foo" or 'foo'.
T_STRINGdoes 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
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