Re: [PHP-DEV] ext/standard/tests/http/bug60570.phpt failure
On Wed, Aug 20, 2014 at 7:24 AM, Dmitry Stogov dmi...@zend.com wrote: Anyone objects about it or thinks it needs RFC? No, goahead :) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 18.08.2014 14:53, Pierre Joye wrote: hi, On Mon, Aug 18, 2014 at 2:44 PM, Marc Bennewitz php@mabe.berlin wrote: On 17.08.2014 22:18, Sara Golemon wrote: On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz php@mabe.berlin wrote: I've created a draft RFC and patch to change the behavior of non-strict string to string comparison to be binary safe (as the strict comparison operator does): https://wiki.php.net/rfc/binary_string_comparison If I understand your goal correctly, you seem to want to change a very fundamental (and ancient) behavior of the language even though mechanisms already exist to do what you describe as the changed behavior. What exactly is wrong with ===, strcmp(), etc..? The question isn't What's wrong with ===, strcmp()? but What's wrong with ==, , ?. And the answer is: not strict and why === exists. Non-strict comparison should do conversion to make both operands comparable. It should not convert both operands into a third unrelated type that wasn't mentioned. Btw. The RFC doesn't handle == and === the same because == *do* type-juggling but only if both operands are not on the same type. strcmp() isn't the same behavior as it first converts both operands into a string. Cheers, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 18.08.2014 17:43, Johannes Schlüter wrote:
On Mon, 2014-08-18 at 17:30 +0200, Johannes Schlüter wrote:
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
echo .htmlentities($row[1])./td/tr;
}
will suddenly fail. How wonderful! (irony)
Just to make this more fun: Assume $db is PDO then the behavior will
depend on the driver (and for some drivers even at the configuration,
i.e. setting of PDO::ATTR_EMULATE_PREPARES with MySQL) what will happen.
I don't understand exactly what you mean here. This RFC has nothing todo
with DB layer and PDO.
Do you have any example where a DB returns integers differently?
On your example the comparison only fails if the GET-variable is a non
human formed integer means prefixing with a whitespace (but not
suffixing), prefixing with a 0 or formed as a real number or hex.
I'm very sure the changed behavior doesn't open big real life BC issues.
I will run some testsuites on it.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/standard/tests/http/bug60570.phpt failure
On Wed, Aug 20, 2014 at 7:24 AM, Dmitry Stogov dmi...@zend.com wrote: Anyone objects about it or thinks it needs RFC? Thanks. Dmitry. On Wed, Aug 20, 2014 at 6:48 AM, Laruence larue...@php.net wrote: Hey: On Tue, Aug 19, 2014 at 10:10 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, Yesterday we discussed with Nikta the failure of ext/standard/tests/http/bug60570.phpt. It was in context of AST patch, but the failure is not related to AST at all. It's just a bad test that makes wrong assumption. Resource leaks can't be caught using get_memory_usage(). To have a robust way to detect resource leaks I propose a new function - get_resources() that returns an array of all registered resources or an array of registered resources of particular type. See patch: https://gist.github.com/dstogov/f96c04f5979e726909ab I'm not sure if such small change needs RFC. Thoughts? I think it's okey to have a such function. we have get_defined_functions/constants/vars thanks I would have then called it get_defined_resources() , for consistency. Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On 20 Aug 2014, at 06:52, Dmitry Stogov dmi...@zend.com wrote: 1) INF conversion to zero seems wrong. May be +INF should be converted to MAX_LONG and -INF to MIN_LONG? I think of Infinity as more of an error value than an actual number. Not using MAX_LONG and MIN_LONG means it casts to the same value matter how large the integer type is, and it happens to be what JavaScript casts Infinity to. There’s also the fringe benefit that 1/0’s result in PHP, FALSE, casts to zero, as Infinity now would also, which is the standard IEEE 754 result for 1/0. 3) a bit unrelated, but it also may make sense to introduce a logical right shift operator ( in Java) How would that function? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 19.08.2014 05:07, Tjerk Meesters wrote:
On Mon, Aug 18, 2014 at 11:30 PM, Johannes Schlüter
johan...@schlueters.de mailto:johan...@schlueters.de wrote:
On Mon, 2014-08-18 at 23:09 +0800, Tjerk Meesters wrote:
On 18 Aug, 2014, at 10:47 pm, Johannes Schlüter
johan...@schlueters.de mailto:johan...@schlueters.de wrote:
On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
The question isn't What's wrong with ===, strcmp()? but
What's wrong
with ==, , ?.
We have a standard way to compare two operands but currently
we do some
magic things to solve something that don't need to be solved.
Still it is a key property of the language which we can't
simply change.
Also mind this: All input data are strings and some databases also
return data as string. So code like
if ($_GET['id'] 0)
or
if ($db-fetchRow()[0] == 12)
which is common will break.
Those two cases will actually not be affected, it's strictly
string=string comparisons that's being discussed here.
Meaning that simple code you find everywhere, in every second tutorial
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
echo .htmlentities($row[1])./td/tr;
}
will suddenly fail. How wonderful! (irony)
Not necessarily and certainly not by definition; reasons for failure are
less obvious such as (but not limited to):
0 == 0.0
11 == 11 (but note that 11 == 11 currently yields false)
0 ==
I'm not arguing for or against this behaviour change, but I found it
necessary to clear up some apparent confusion as to what repercussions
this proposal carries.
Another approach of attempting to solve the common issue of comparing
big numbers with '==' is to only enforce string-wise comparison if a
number cast would cause precision loss.
That's a good point, too
johannes
ps. yes, the example might be done nicer and better, it still represents
a common pattern.
--
--
Tjerk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On 20 Aug 2014, at 03:53, Laruence larue...@php.net wrote: On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote: Good evening, I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics I'd like don't change the works behavior. make it act the similar as C does. For some of these things the behaviour is explicitly undefined in C, meaning it’s dangerous for us not to handle them specially, as undefined behaviour seems to give compilers an unlimited license to do absolutely anything at all. The rest are “implementation-defined”. While what C does “works”, I’d rather we do one thing consistently instead of forcing developers to deal with the kinds of platform and compiler differences tools like PHP should be abstracting. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On Tue, Aug 19, 2014 at 11:07 AM, Tjerk Meesters tjerk.meest...@gmail.com
wrote:
On Mon, Aug 18, 2014 at 11:30 PM, Johannes Schlüter
johan...@schlueters.de wrote:
On Mon, 2014-08-18 at 23:09 +0800, Tjerk Meesters wrote:
On 18 Aug, 2014, at 10:47 pm, Johannes Schlüter
johan...@schlueters.de wrote:
On Mon, 2014-08-18 at 14:44 +0200, Marc Bennewitz wrote:
The question isn't What's wrong with ===, strcmp()? but What's
wrong
with ==, , ?.
We have a standard way to compare two operands but currently we do
some
magic things to solve something that don't need to be solved.
Still it is a key property of the language which we can't simply
change.
Also mind this: All input data are strings and some databases also
return data as string. So code like
if ($_GET['id'] 0)
or
if ($db-fetchRow()[0] == 12)
which is common will break.
Those two cases will actually not be affected, it's strictly
string=string comparisons that's being discussed here.
Meaning that simple code you find everywhere, in every second tutorial
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
echo .htmlentities($row[1])./td/tr;
}
will suddenly fail. How wonderful! (irony)
Not necessarily and certainly not by definition; reasons for failure are
less obvious such as (but not limited to):
0 == 0.0
11 == 11 (but note that 11 == 11 currently yields false)
0 ==
I had mistakenly assumed that 0 == would currently yield true, but it
doesn't. My apologies for that. The other two statements are still valid,
though. So are these:
0 == 0x0
0 == 00
I'm not arguing for or against this behaviour change, but I found it
necessary to clear up some apparent confusion as to what repercussions this
proposal carries.
Another approach of attempting to solve the common issue of comparing big
numbers with '==' is to only enforce string-wise comparison if a number
cast would cause precision loss.
johannes
ps. yes, the example might be done nicer and better, it still represents
a common pattern.
--
--
Tjerk
--
--
Tjerk
Re: [PHP-DEV] [RFC] Integer Semantics
On Wed, Aug 20, 2014 at 11:24 AM, Andrea Faulds a...@ajf.me wrote: On 20 Aug 2014, at 03:53, Laruence larue...@php.net wrote: On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote: Good evening, I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics I'd like don't change the works behavior. make it act the similar as C does. For some of these things the behaviour is explicitly undefined in C, meaning it’s dangerous for us not to handle them specially, as undefined behaviour seems to give compilers an unlimited license to do absolutely anything at all. The rest are “implementation-defined”. While what C does “works”, I’d rather we do one thing consistently instead of forcing developers to deal with the kinds of platform and compiler differences tools like PHP should be abstracting. I totally agree with Andrea here. While it made sense to map C behavior for years, for many of us, as we all came from a C backgroud. However it makes less and less sense lately, if at all. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On Wed, Aug 20, 2014 at 1:20 PM, Andrea Faulds a...@ajf.me wrote: On 20 Aug 2014, at 06:52, Dmitry Stogov dmi...@zend.com wrote: 1) INF conversion to zero seems wrong. May be +INF should be converted to MAX_LONG and -INF to MIN_LONG? I think of Infinity as more of an error value than an actual number. Not using MAX_LONG and MIN_LONG means it casts to the same value matter how large the integer type is, and it happens to be what JavaScript casts Infinity to. There’s also the fringe benefit that 1/0’s result in PHP, FALSE, casts to zero, as Infinity now would also, which is the standard IEEE 754 result for 1/0. 3) a bit unrelated, but it also may make sense to introduce a logical right shift operator ( in Java) The difference between arithmetic and logical shift is sign propagation. 0x1000 1 == 0x1100 0x1000 1 == 0x0100 In C the same operator perform arithmetic shift for signed numbers and logical shift for unsigned. Thanks. Dmitry. How would that function? -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] ext/standard/tests/http/bug60570.phpt failure
The are not defined. They are open (or closed but not freed yet). You probably meant get_defined_resorce_types() Thanks. Dmitry. On Wed, Aug 20, 2014 at 1:12 PM, Julien Pauli jpa...@php.net wrote: On Wed, Aug 20, 2014 at 7:24 AM, Dmitry Stogov dmi...@zend.com wrote: Anyone objects about it or thinks it needs RFC? Thanks. Dmitry. On Wed, Aug 20, 2014 at 6:48 AM, Laruence larue...@php.net wrote: Hey: On Tue, Aug 19, 2014 at 10:10 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, Yesterday we discussed with Nikta the failure of ext/standard/tests/http/bug60570.phpt. It was in context of AST patch, but the failure is not related to AST at all. It's just a bad test that makes wrong assumption. Resource leaks can't be caught using get_memory_usage(). To have a robust way to detect resource leaks I propose a new function - get_resources() that returns an array of all registered resources or an array of registered resources of particular type. See patch: https://gist.github.com/dstogov/f96c04f5979e726909ab I'm not sure if such small change needs RFC. Thoughts? I think it's okey to have a such function. we have get_defined_functions/constants/vars thanks I would have then called it get_defined_resources() , for consistency. Julien.P
Re: [PHP-DEV] master is broken on Travis
On Tue, Aug 19, 2014 at 1:46 AM, Bob Weinand bobw...@hotmail.com wrote: Am 19.8.2014 um 00:09 schrieb Stas Malyshev smalys...@sugarcrm.com: Hi! Since we've had phpng branch merged to master the build on Travis CI is broken for master (as in, doesn't even build). Could it be fixed? It's not a good thing that we have master branch that CI can not even run on. I suspect it has to do with phpdbg but didn't look into it in depth. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ Hi, yes, phpdbg is not ported yet to phpng. I planned to port it when I have time, that'll be in first week of September. Until then, feel free to remove phpdbg from travis build. (I'll add it then again) Removed phpdbg build from configure, and master builds fine. Removed its tests as well to have travis finish green. Kaplan
Re: [PHP-DEV] [RFC] Binary String Comparison
On 20/08/14 11:12, Marc Bennewitz wrote:
On 18.08.2014 17:43, Johannes Schlüter wrote:
On Mon, 2014-08-18 at 17:30 +0200, Johannes Schlüter wrote:
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
echo .htmlentities($row[1])./td/tr;
}
will suddenly fail. How wonderful! (irony)
Just to make this more fun: Assume $db is PDO then the behavior will
depend on the driver (and for some drivers even at the configuration,
i.e. setting of PDO::ATTR_EMULATE_PREPARES with MySQL) what will happen.
I don't understand exactly what you mean here. This RFC has nothing todo
with DB layer and PDO.
Do you have any example where a DB returns integers differently?
php -r '$p = new PDO(mysql:user=root); \
$s=$p-prepare(SELECT 1); $s-execute(); \
var_dump($s-fetchAll()); \
$p-setAttribute(PDO::ATTR_EMULATE_PREPARES,false); \
$s=$p-prepare(SELECT 1); $s-execute(); \
var_dump($s-fetchAll());'
array(1) {
[0]=
array(2) {
[1]=
string(1) 1
[2]=
string(1) 1
}
}
array(1) {
[0]=
array(2) {
[1]=
int(1)
[2]=
int(1)
}
}
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE][RFC] Closure::apply() (re-opening)
Good afternoon, I’m putting this RFC to a vote again as I haven’t heard any objections in the past three days, and in the event something’s been missed, one week would be long enough to spot it. Vote is here: https://wiki.php.net/rfc/closure_apply#vote It ends 2014-08-27. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans a...@zend.com wrote: Hi Nikita, I reviewed the AST RFC on my way to vote but there was something that wasn’t clear to me. This patch introduces some semantic/behavioral changes in addition to the AST. Are these as a side-effect of how AST was implemented? Or are they unrelated to the AST patch? I think some of them make sense but I’m having a bit of a hard time separating out the benefits of the AST (which I really like) and making other changes to semantics w/o really understanding if they are side-effects and we have no choice vs. we’re trying to solve for two separate items in one RFC. Any BC breaks here we think could bite us? Hi Nikita, I second some of Andi's concerns about behavioural changes, some things working from right-to-left and not left-to-right. Are these things that we can adapt the AST part or tweak another part to make this more consistent with previous versions of PHP. Improving consistency when changing underlying parts is a good migration technique. Facebook done this when they implemented HHMV, they didn't fix bugs but made a like-for-like stable copy before tackling improvements. Do you feel it's an important goal to keep consistency from PHP 5.x to PHP 7, with regards to the behaviour of syntax parsing/behaviour, or do you feel that you can live with these non-BC changes? Many thanks, Paul Any insight would be much appreciated. Thanks! Andi On Aug 18, 2014, at 9:41 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! I've opened the vote on the Abstract Syntax Tree RFC: https://wiki.php.net/rfc/abstract_syntax_tree#vote Thanks, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Wed, Aug 20, 2014 at 3:30 PM, Paul Dragoonis dragoo...@gmail.com wrote: Hi Nikita, I second some of Andi's concerns about behavioural changes, some things working from right-to-left and not left-to-right. Are these things that we can adapt the AST part or tweak another part to make this more consistent with previous versions of PHP. Improving consistency when changing underlying parts is a good migration technique. Facebook done this when they implemented HHMV, they didn't fix bugs but made a like-for-like stable copy before tackling improvements. Do you feel it's an important goal to keep consistency from PHP 5.x to PHP 7, with regards to the behaviour of syntax parsing/behaviour, or do you feel that you can live with these non-BC changes? Many thanks, Paul Is there some *particular* change that concerns you? This is something that needs to be decided on a case-by-case basis. The RFC contains a list of changes. All of them are minor adjustments verging on bug fixes, which imho are all within the bounds of reasonable changes for a major version. However if you can provide argument why one of the listed changes is incorrect (as in, introduces less intuitive/consistent/... behavior) or has larger BC impact than anticipated, then I'm open to discussion that. Nikita
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Wed, Aug 20, 2014 at 2:57 PM, Nikita Popov nikita@gmail.com wrote: On Wed, Aug 20, 2014 at 3:30 PM, Paul Dragoonis dragoo...@gmail.com wrote: Hi Nikita, I second some of Andi's concerns about behavioural changes, some things working from right-to-left and not left-to-right. Are these things that we can adapt the AST part or tweak another part to make this more consistent with previous versions of PHP. Improving consistency when changing underlying parts is a good migration technique. Facebook done this when they implemented HHMV, they didn't fix bugs but made a like-for-like stable copy before tackling improvements. Do you feel it's an important goal to keep consistency from PHP 5.x to PHP 7, with regards to the behaviour of syntax parsing/behaviour, or do you feel that you can live with these non-BC changes? Many thanks, Paul Is there some *particular* change that concerns you? This is something that needs to be decided on a case-by-case basis. The RFC contains a list of changes. All of them are minor adjustments verging on bug fixes, which imho are all within the bounds of reasonable changes for a major version. However if you can provide argument why one of the listed changes is incorrect (as in, introduces less intuitive/consistent/... behavior) or has larger BC impact than anticipated, then I'm open to discussion that. I will get back to you with some specific use cases that I see could be potentially problematic and non-intuitive. Nikita
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Wed, Aug 20, 2014 at 7:30 AM, Paul Dragoonis dragoo...@gmail.com wrote: On Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans a...@zend.com wrote: Hi Nikita, I reviewed the AST RFC on my way to vote but there was something that wasn’t clear to me. This patch introduces some semantic/behavioral changes in addition to the AST. Are these as a side-effect of how AST was implemented? Or are they unrelated to the AST patch? I think some of them make sense but I’m having a bit of a hard time separating out the benefits of the AST (which I really like) and making other changes to semantics w/o really understanding if they are side-effects and we have no choice vs. we’re trying to solve for two separate items in one RFC. Any BC breaks here we think could bite us? Hi Nikita, I second some of Andi's concerns about behavioural changes, some things working from right-to-left and not left-to-right. Are these things that we can adapt the AST part or tweak another part to make this more consistent with previous versions of PHP. I just had a chat with Paul about this, and there was a misunderstanding about what this RFC actually does regarding left-to-right evaluation on list() constructs. I also saw this misunderstanding in a few other places, so it seems to be a common misunderstanding. Under the proposed changes as well as in PHP 5.x, the end result of the following is the same: list($a, $b) = array(1, 2); $a will be 1 and $b will be 2. Again, this hasn't changed. The difference is that in PHP 5.x the variable $b will be assigned 2 before $a is assigned 1; under these changes $a will be assigned 1 first and then $b will be assigned 2. This really only affects strange situations, such as ones listed in the RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 20.08.2014 12:46, Michael Wallner wrote:
On 20/08/14 11:12, Marc Bennewitz wrote:
On 18.08.2014 17:43, Johannes Schlüter wrote:
On Mon, 2014-08-18 at 17:30 +0200, Johannes Schlüter wrote:
foreach ($db-query(SELECT id, title FROM entries) as $row) {
echo trtd;
if ($row[0] == $_GET['highlight_id']) {
echo background='#ff';
}
echo .htmlentities($row[1])./td/tr;
}
will suddenly fail. How wonderful! (irony)
Just to make this more fun: Assume $db is PDO then the behavior will
depend on the driver (and for some drivers even at the configuration,
i.e. setting of PDO::ATTR_EMULATE_PREPARES with MySQL) what will happen.
I don't understand exactly what you mean here. This RFC has nothing todo
with DB layer and PDO.
Do you have any example where a DB returns integers differently?
php -r '$p = new PDO(mysql:user=root); \
$s=$p-prepare(SELECT 1); $s-execute(); \
var_dump($s-fetchAll()); \
$p-setAttribute(PDO::ATTR_EMULATE_PREPARES,false); \
$s=$p-prepare(SELECT 1); $s-execute(); \
var_dump($s-fetchAll());'
array(1) {
[0]=
array(2) {
[1]=
string(1) 1
[2]=
string(1) 1
}
}
array(1) {
[0]=
array(2) {
[1]=
int(1)
[2]=
int(1)
}
}
Thank's for the explanation, but this is nothing that runs into issues
because:
- In case 1 the result number will be a string 1 that is equal with
another string of 1. Only if 1 will be compared to something like
01, 1, 0x1 the result will no longer be the same.
- In case 2 the DB layer already returns an integer and on comparing
this to a string the string will be converted to an integer, too -
nothing changed here by the RFC
To make the example of Johannes fail the DB layer have to return the
integer as string but not formed in a standard human way.
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Closure::apply() (re-opening)
The only thing I'd suggest is like I said in the last email is to make the syntax more like Closure::bind(Closure $closure, object $newThis, [mixed $newScope = 'static']) and make it Closure::apply(mixed $newObjectOrScope [, mixed ... $parameters]) $newObjectOrScope would then allow a user to supply a class name or an object. If class name is passed you have access to static::, self::, and parent:: inside the function everything else works as described in the RFC. Give the ability to call a closure as a static method of a class or a normal method of an object. Right now the only way to do it is doing binding and creating new closures and calling those closures then destroying them. On Wed, Aug 20, 2014 at 7:50 AM, Andrea Faulds a...@ajf.me wrote: Good afternoon, I’m putting this RFC to a vote again as I haven’t heard any objections in the past three days, and in the event something’s been missed, one week would be long enough to spot it. Vote is here: https://wiki.php.net/rfc/closure_apply#vote It ends 2014-08-27. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 security only
On 19/08/14 01:59, Stas Malyshev wrote: - EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into 5.4 branch unless they are very important ones (and that is only because people may, in theory, have pending patches and we didn't give advance notice). Importance would have to be determined somewhat arbitrarily, but basically if it works without it, then it's not in, if there's serious doubt if it should be in, it's not in, etc. Security issues, of course, still allowed in. Hey Stas! Apparently the fix for #67724 [2] caused #67865 [1], but I already have a fix for the fix (oh my) [3]. The question is whether to commit the fix or revert e4ff7f2e in 5.4? https://bugs.php.net/bug.php?id=67865 https://bugs.php.net/bug.php?id=67724 http://pastebin.com/0wJcLqY1 -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 20.08.2014 19:50, Ferenc Kovacs wrote: 2014.08.17. 21:59 ezt írta (Marc Bennewitz php@mabe.berlin): Hi internals! I've created a draft RFC and patch to change the behavior of non-strict string to string comparison to be binary safe (as the strict comparison operator does): https://wiki.php.net/rfc/binary_string_comparison On comparing two numeric strings both operands will be equal if the string representation will be the same. On comparing two numeric strings the first operand will be greater if the first not matching byte will be higher. On comparing two numeric strings the first operand will be lower if the first not matching byte will be lower. As a side effect it makes string comparison much faster and force developer to really write what they mean (No need to guess) and to force developers to cast/filter input once which also affects performance. On C-Level the function zendi_smart_strcmp will be unused and marked as deprecated. Thanks, Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Maybe it was already mentionex, but just to make sure: this would fix issues like https://bugs.php.net/bug.php?id=54547 Yes, such comparison issues will go away! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/standard/tests/http/bug60570.phpt failure
Hello Dmitry, On 20.08.2014 12:08, Dmitry Stogov wrote: To have a robust way to detect resource leaks I propose a new function - get_resources() that returns an array of all registered resources or an array of registered resources of particular type. See patch: https://gist.github.com/dstogov/f96c04f5979e726909ab my only concern would be the naming? Is there a policy for introducing new global symbols in PHP? Looking at get_resources it doesn't look far way from get_header or similar related stuff. A quick search on github should only some very very few results so it's probably statistically irrelevant. I was just wondering in general how introducing global symbols without documented patterns (like __... methods) works? thank you, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Closure::apply() (re-opening)
On Wed, Aug 20, 2014 at 11:51 AM, Nathan nathan.br...@starin.biz wrote: The only thing I'd suggest is like I said in the last email is to make the syntax more like Closure::bind(Closure $closure, object $newThis, [mixed $newScope = 'static']) and make it Closure::apply(mixed $newObjectOrScope [, mixed ... $parameters]) $newObjectOrScope would then allow a user to supply a class name or an object. If class name is passed you have access to static::, self::, and parent:: inside the function everything else works as described in the RFC. Give the ability to call a closure as a static method of a class or a normal method of an object. Right now the only way to do it is doing binding and creating new closures and calling those closures then destroying them. I think you are confused. This proposal basically binds the closure to the new object and invokes it immediately. I genuinely don't see how it being statically bound to the object will make a difference. Please elaborate. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 20 Aug 2014, at 19:36, Marc Bennewitz php@mabe.berlin wrote: On 20.08.2014 19:50, Ferenc Kovacs wrote: Maybe it was already mentionex, but just to make sure: this would fix issues like https://bugs.php.net/bug.php?id=54547 Yes, such comparison issues will go away! It would, however, introduce new ones. We should be careful here. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improved logarithm of base 2|10 of standard math function
On 19.08.2014 00:41, Stas Malyshev wrote: Hi! I opted for master-only on the grounds that while it's an improvement, it's not really a bugfix, and released versions (or versions as near to release as 5.6 is) should be bug-fix only. I know there's an argument for this *being* a bug-fix, but... If a consensus feels it should be merged back I won't object. I think we can have it in 5.6 and 5.5. 5.4 being very close to security-only (with the switch technically being already past due) I'd not merge something that works without the fix back there. 5.5 and 5.6 would be very OK for me :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 security only
Hi! Apparently the fix for #67724 [2] caused #67865 [1], but I already have a fix for the fix (oh my) [3]. I've reverted it from 5.4.32, but please commit this fix in 5.4. As phar is currently broken, fix for this qualifies as important. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/standard/tests/http/bug60570.phpt failure
Hi! array of registered resources of particular type. See patch: https://gist.github.com/dstogov/f96c04f5979e726909ab It would be better as a pull, it's be easier to comment on it. For the function get_resources, the proto says it has no arguments, but it actually has one S argument that is not documented. Could you add a proto for it? I'm not sure if such small change needs RFC. I don't think so, seems to be pretty non-controversial. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] master is broken on Travis
Hi! Removed phpdbg build from configure, and master builds fine. Removed its tests as well to have travis finish green. Did you commit it? I see Travis CI build is still broken. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/standard/tests/http/bug60570.phpt failure
done. Dmitry. On Thu, Aug 21, 2014 at 12:50 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! array of registered resources of particular type. See patch: https://gist.github.com/dstogov/f96c04f5979e726909ab It would be better as a pull, it's be easier to comment on it. For the function get_resources, the proto says it has no arguments, but it actually has one S argument that is not documented. Could you add a proto for it? I'm not sure if such small change needs RFC. I don't think so, seems to be pretty non-controversial. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/
