Re: [PHP-DEV] Headsup: PHP7 feature freeze
Hi Anatol, - Original Message - From: Anatol Belski Sent: Monday, July 07, 2015 Hi Matt, -Original Message- From: Matt Wilmas [mailto:php_li...@realplain.com] Sent: Tuesday, July 7, 2015 4:10 AM To: Internals; Kalle Sommer Nielsen Cc: Anatoliy Belsky; Dmitry Stogov; Nikita Popov; Ferenc Kovacs; Xinchen Hui Subject: Re: [PHP-DEV] Headsup: PHP7 feature freeze Hello RMs, all! - Original Message - From: Kalle Sommer Nielsen Sent: Thursday, June 25, 2015 Howdy This is a quick heads up that we plan to have the next release of 7.0.0 be Beta 1, this marks a feature freeze and from there on, we will switch focus on to stabilization, regressions and other bug fixes. Beta 1 is schedule to be tagged and packaged on July 7th and released on July 9th which is a small 2 weeks from now to get any remaining changes of such in. If you are in doubt about whether or not your change would be considered a 'feature' or have any other questions, then feel free to mail us RMs or reply here. I intended to reply to this shortly after, and I guess there isn't much reason to now. :-) I started messing with the parameter parsing stuff, which I thought would take a couple days max, but I got deep into it. Message coming sometime soon about that... Anyway, I was wanting to do some enhancements to the Postgres extension, and I was hopeful they could be included for 7 until I saw this message and thought, Uh-oh. Until the ZPP thing, I hoped I'd have the basics of the features whipped up by the end of last week (not that I thought anything could be commited immediately ;-)). Is this the shortest Alpha period ever? (Serious question. :-)) If I had really jumped on the work (I had to get up to speed on some new-to-me internals), I could have been maybe a month sooner. But when I saw the wiki timetable, I thought there'd been until August or so after 3-4 Alphas... *shrug* So if there are 9 releases before final, there's going to be 4-5 Betas and 4-5 RCs? I thought there'd be more even distribution. Well, the Postgres stuff comes from the fact that I just discovered it (truly, in- depth) about 10 weeks ago. (Life changing!) Of course shortly after something led me to start looking into PHP's code, after already being disappointed. As I analyzed things more, I figured I could actually fulfill my own wishlist. :-D The main feature is very straight-forward (almost search-and-replace!). The other feature group I'm not sure what thoughts will be about usability/implementation, but it shouldn't be that big either, and totally isolated from existing functionality. BTW, there are *several* other issues with the extension's code, that I started noticing right away. I literally lost track, didn't note them; but hopefully can clean them all up. Of course these can all be done, and also applied to 5.6, AFAIK. If we can have these changes sometime, it'd be nice if it was before 7.1... Of course, for my personal use, I really don't care since I can use them right away. But I think the PHP-Postgres community needs them and would be glad! Thanks for the suggestion. Do you already have some code to show? No, not yet. But I'll still go ahead and send my proposed changes when I get to it fairly soon. Like I said, I want this for my own use at least, so the sooner it's done, the better. :-) Back in May I thought I'd first try to fix the different issues I noticed, but at this point, it's probably better to focus on the features part, and then do the other stuff after. I don't think there's much overlap... Regards Anatol Thanks, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
Hello RMs, all! - Original Message - From: Kalle Sommer Nielsen Sent: Thursday, June 25, 2015 Howdy This is a quick heads up that we plan to have the next release of 7.0.0 be Beta 1, this marks a feature freeze and from there on, we will switch focus on to stabilization, regressions and other bug fixes. Beta 1 is schedule to be tagged and packaged on July 7th and released on July 9th which is a small 2 weeks from now to get any remaining changes of such in. If you are in doubt about whether or not your change would be considered a 'feature' or have any other questions, then feel free to mail us RMs or reply here. I intended to reply to this shortly after, and I guess there isn't much reason to now. :-) I started messing with the parameter parsing stuff, which I thought would take a couple days max, but I got deep into it. Message coming sometime soon about that... Anyway, I was wanting to do some enhancements to the Postgres extension, and I was hopeful they could be included for 7 until I saw this message and thought, Uh-oh. Until the ZPP thing, I hoped I'd have the basics of the features whipped up by the end of last week (not that I thought anything could be commited immediately ;-)). Is this the shortest Alpha period ever? (Serious question. :-)) If I had really jumped on the work (I had to get up to speed on some new-to-me internals), I could have been maybe a month sooner. But when I saw the wiki timetable, I thought there'd been until August or so after 3-4 Alphas... *shrug* So if there are 9 releases before final, there's going to be 4-5 Betas and 4-5 RCs? I thought there'd be more even distribution. Well, the Postgres stuff comes from the fact that I just discovered it (truly, in-depth) about 10 weeks ago. (Life changing!) Of course shortly after something led me to start looking into PHP's code, after already being disappointed. As I analyzed things more, I figured I could actually fulfill my own wishlist. :-D The main feature is very straight-forward (almost search-and-replace!). The other feature group I'm not sure what thoughts will be about usability/implementation, but it shouldn't be that big either, and totally isolated from existing functionality. BTW, there are *several* other issues with the extension's code, that I started noticing right away. I literally lost track, didn't note them; but hopefully can clean them all up. Of course these can all be done, and also applied to 5.6, AFAIK. If we can have these changes sometime, it'd be nice if it was before 7.1... Of course, for my personal use, I really don't care since I can use them right away. But I think the PHP-Postgres community needs them and would be glad! Thanks, Kalle, Anatol Ferenc Thanks, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Headsup: PHP7 feature freeze
Hi Matt, -Original Message- From: Matt Wilmas [mailto:php_li...@realplain.com] Sent: Tuesday, July 7, 2015 4:10 AM To: Internals; Kalle Sommer Nielsen Cc: Anatoliy Belsky; Dmitry Stogov; Nikita Popov; Ferenc Kovacs; Xinchen Hui Subject: Re: [PHP-DEV] Headsup: PHP7 feature freeze Hello RMs, all! - Original Message - From: Kalle Sommer Nielsen Sent: Thursday, June 25, 2015 Howdy This is a quick heads up that we plan to have the next release of 7.0.0 be Beta 1, this marks a feature freeze and from there on, we will switch focus on to stabilization, regressions and other bug fixes. Beta 1 is schedule to be tagged and packaged on July 7th and released on July 9th which is a small 2 weeks from now to get any remaining changes of such in. If you are in doubt about whether or not your change would be considered a 'feature' or have any other questions, then feel free to mail us RMs or reply here. I intended to reply to this shortly after, and I guess there isn't much reason to now. :-) I started messing with the parameter parsing stuff, which I thought would take a couple days max, but I got deep into it. Message coming sometime soon about that... Anyway, I was wanting to do some enhancements to the Postgres extension, and I was hopeful they could be included for 7 until I saw this message and thought, Uh-oh. Until the ZPP thing, I hoped I'd have the basics of the features whipped up by the end of last week (not that I thought anything could be commited immediately ;-)). Is this the shortest Alpha period ever? (Serious question. :-)) If I had really jumped on the work (I had to get up to speed on some new-to-me internals), I could have been maybe a month sooner. But when I saw the wiki timetable, I thought there'd been until August or so after 3-4 Alphas... *shrug* So if there are 9 releases before final, there's going to be 4-5 Betas and 4-5 RCs? I thought there'd be more even distribution. Well, the Postgres stuff comes from the fact that I just discovered it (truly, in- depth) about 10 weeks ago. (Life changing!) Of course shortly after something led me to start looking into PHP's code, after already being disappointed. As I analyzed things more, I figured I could actually fulfill my own wishlist. :-D The main feature is very straight-forward (almost search-and-replace!). The other feature group I'm not sure what thoughts will be about usability/implementation, but it shouldn't be that big either, and totally isolated from existing functionality. BTW, there are *several* other issues with the extension's code, that I started noticing right away. I literally lost track, didn't note them; but hopefully can clean them all up. Of course these can all be done, and also applied to 5.6, AFAIK. If we can have these changes sometime, it'd be nice if it was before 7.1... Of course, for my personal use, I really don't care since I can use them right away. But I think the PHP-Postgres community needs them and would be glad! Thanks for the suggestion. Do you already have some code to show? Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Headsup: PHP7 feature freeze
Hi Yasuo, -Original Message- From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki Sent: Friday, June 26, 2015 1:58 PM To: Hannes Magnusson Cc: Kalle Sommer Nielsen; Internals; Anatoliy Belsky; Dmitry Stogov; Nikita Popov; Ferenc Kovacs; Xinchen Hui Subject: Re: [PHP-DEV] Headsup: PHP7 feature freeze Hi all, On Fri, Jun 26, 2015 at 12:56 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Hannes, On Fri, Jun 26, 2015 at 12:51 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Why do you think its undocumented? http://php.net/manual/en/sessionhandler.create-sid.php Rename discussion was there. And I explicitly discussed it's undocumented and it violates CODING_STANDARDS, but it was added recently (after the discussion I suppose). [yohgaki@dev session]$ svn log -r 334814 - --- r334814 | aharvey | 2014-09-09 04:49:26 +0900 (2014年09月09日 (火)) | 2 lines Add documentation for SessionHandler::create_sid(). - --- 334814aharvey classnameSessionHandler/classname is a special class that can be used 334814aharvey to expose the current internal PHP session save handler by inheritance. 334814aharvey There are seven methods which wrap the seven internal session save handler 334814aharvey callbacks (parameteropen/parameter, parameterclose/parameter, 334814aharvey parameterread/parameter, parameterwrite/parameter, 334814aharvey parameterdestroy/parameter, parametergc/parameter and 334814aharvey parametercreate_sid/parameter). By default, this class will wrap 334814aharvey whatever internal save handler is set as defined by the 334814aharvey link linkend=ini.session.save-handlersession.save_handler/link 334814aharvey configuration directive which is usually parameterfiles/parameter by 334814aharvey default. Other internal session save handlers are provided by PHP 334814aharvey extensions such as SQLite (as parametersqlite/parameter), Memcache (as 334814aharvey parametermemcache/parameter), and Memcached (as 334814aharvey parametermemcached/parameter). I think this should be reverted. Or it may stay there. It's just a matter of having a copy of create_sid(). I'll add documentation. I forgot that session_create_id() is needed createSid() method to be more useful. The code for session_create_id() is in the source, but it isn't enabled. I wouldn't like to have different naming session_create_id() and createSid(). So I would like to have - session_create_id() function - createId() function because there is - session_id() since PHP4. I don't think session internal names do not have to be changed. i.e. Macros, etc. Any comments? Changing internal or user space API is kind of too late, IMHO. Especially the user space APIs that are documented. But also the internals, as a lot of extensions are already ported. Also because sessions are a core functionality where changes should be supported but a good migration path. Please target later 7.x versions with this change. But probably would make sense to create an RFC and start the discussion like already... yesterday, so the topic is good discussed and accepted for the next. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
2015-06-28 22:19 GMT+02:00 Anatol Belski anatol@belski.net: What is the benefit changing it? XHTML is a standard which is alive. That's on every person's opinion. XHTML is currently not a standard, XHTML is dead. But, there's for sure some code based on parsing the phpinfo() output, since not everything is exported as a constant. IMHO having HTML5 in phpinfo(), while being nice, doesn't justify itself breaking those codes. Okay, that could be an argument. So I will rather focus on replacing just these completely legacy things like a name or font etc. (plus inline styles to make the HTML code more readable and self-explainable). I would argue that software can be updated, but... okay, let it be. Best regards, Kubo2, Jakub Kubíček -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
Hi Anatol, On Mon, Jun 29, 2015 at 10:19 PM, Anatol Belski anatol@belski.net wrote: -Original Message- From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki Sent: Friday, June 26, 2015 1:58 PM To: Hannes Magnusson Cc: Kalle Sommer Nielsen; Internals; Anatoliy Belsky; Dmitry Stogov; Nikita Popov; Ferenc Kovacs; Xinchen Hui Subject: Re: [PHP-DEV] Headsup: PHP7 feature freeze Hi all, On Fri, Jun 26, 2015 at 12:56 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Hannes, On Fri, Jun 26, 2015 at 12:51 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Why do you think its undocumented? http://php.net/manual/en/sessionhandler.create-sid.php Rename discussion was there. And I explicitly discussed it's undocumented and it violates CODING_STANDARDS, but it was added recently (after the discussion I suppose). [yohgaki@dev session]$ svn log -r 334814 - --- r334814 | aharvey | 2014-09-09 04:49:26 +0900 (2014年09月09日 (火)) | 2 lines Add documentation for SessionHandler::create_sid(). - --- 334814aharvey classnameSessionHandler/classname is a special class that can be used 334814aharvey to expose the current internal PHP session save handler by inheritance. 334814aharvey There are seven methods which wrap the seven internal session save handler 334814aharvey callbacks (parameteropen/parameter, parameterclose/parameter, 334814aharvey parameterread/parameter, parameterwrite/parameter, 334814aharvey parameterdestroy/parameter, parametergc/parameter and 334814aharvey parametercreate_sid/parameter). By default, this class will wrap 334814aharvey whatever internal save handler is set as defined by the 334814aharvey link linkend=ini.session.save-handlersession.save_handler/link 334814aharvey configuration directive which is usually parameterfiles/parameter by 334814aharvey default. Other internal session save handlers are provided by PHP 334814aharvey extensions such as SQLite (as parametersqlite/parameter), Memcache (as 334814aharvey parametermemcache/parameter), and Memcached (as 334814aharvey parametermemcached/parameter). I think this should be reverted. Or it may stay there. It's just a matter of having a copy of create_sid(). I'll add documentation. I forgot that session_create_id() is needed createSid() method to be more useful. The code for session_create_id() is in the source, but it isn't enabled. I wouldn't like to have different naming session_create_id() and createSid(). So I would like to have - session_create_id() function - createId() function because there is - session_id() since PHP4. I don't think session internal names do not have to be changed. i.e. Macros, etc. Any comments? Changing internal or user space API is kind of too late, IMHO. Especially the user space APIs that are documented. But also the internals, as a lot of extensions are already ported. Also because sessions are a core functionality where changes should be supported but a good migration path. Please target later 7.x versions with this change. But probably would make sense to create an RFC and start the discussion like already... yesterday, so the topic is good discussed and accepted for the next. No problem. I'll write a RFC for this. For the record, please don't document questionable APIs... I'll add comment to source if there are similar cases. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On Mon, Jun 29, 2015 at 11:31 PM, Levi Morrison le...@php.net wrote: On Mon, Jun 29, 2015 at 3:47 PM, Jakub Kubíček kelerest...@gmail.com wrote: 2015-06-28 22:19 GMT+02:00 Anatol Belski anatol@belski.net: What is the benefit changing it? XHTML is a standard which is alive. That's on every person's opinion. XHTML is currently not a standard, XHTML is dead. But, there's for sure some code based on parsing the phpinfo() output, since not everything is exported as a constant. IMHO having HTML5 in phpinfo(), while being nice, doesn't justify itself breaking those codes. Okay, that could be an argument. So I will rather focus on replacing just these completely legacy things like a name or font etc. (plus inline styles to make the HTML code more readable and self-explainable). I would argue that software can be updated, but... okay, let it be. Best regards, Kubo2, Jakub Kubíček -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php (Sorry for previous blank email) XHTML is preferable to HTML for many people because tools for XML are stable and mature. Even HTML 5 is permitted to be serialized as XHTML (meaning you close tags that do not technically need to be closed, you self-close certain tags, etc). If we move to HTML 5 there is definite value to making sure it is XHTML compatible. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On Mon, Jun 29, 2015 at 3:47 PM, Jakub Kubíček kelerest...@gmail.com wrote: 2015-06-28 22:19 GMT+02:00 Anatol Belski anatol@belski.net: What is the benefit changing it? XHTML is a standard which is alive. That's on every person's opinion. XHTML is currently not a standard, XHTML is dead. But, there's for sure some code based on parsing the phpinfo() output, since not everything is exported as a constant. IMHO having HTML5 in phpinfo(), while being nice, doesn't justify itself breaking those codes. Okay, that could be an argument. So I will rather focus on replacing just these completely legacy things like a name or font etc. (plus inline styles to make the HTML code more readable and self-explainable). I would argue that software can be updated, but... okay, let it be. Best regards, Kubo2, Jakub Kubíček -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
Hi RMs, I have a pending change here http://github.com/php/php-src/pull/1301 which is however not ready to be merged yet. I am currently working on it locally to do some more improvements for phpinfo(). I wanna ask you if you consider it a feature and thus if I have to finish it before the first beta is released if I wanna include it in PHP7 or rather to target it against PHP 7.1. Thanks for your reply. Best regards Kubo2, Jakub Kubíček 2015-06-25 17:03 GMT+02:00 Kalle Sommer Nielsen ka...@php.net: Howdy This is a quick heads up that we plan to have the next release of 7.0.0 be Beta 1, this marks a feature freeze and from there on, we will switch focus on to stabilization, regressions and other bug fixes. Beta 1 is schedule to be tagged and packaged on July 7th and released on July 9th which is a small 2 weeks from now to get any remaining changes of such in. If you are in doubt about whether or not your change would be considered a 'feature' or have any other questions, then feel free to mail us RMs or reply here. Thanks, Kalle, Anatol Ferenc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Headsup: PHP7 feature freeze
Hi Jakub, -Original Message- From: Jakub Kubíček [mailto:kelerest...@gmail.com] Sent: Sunday, June 28, 2015 4:03 PM To: Kalle Sommer Nielsen; Internals Cc: Anatoliy Belsky; Dmitry Stogov; Nikita Popov; Ferenc Kovacs; Xinchen Hui Subject: Re: [PHP-DEV] Headsup: PHP7 feature freeze Hi RMs, I have a pending change here http://github.com/php/php-src/pull/1301 which is however not ready to be merged yet. I am currently working on it locally to do some more improvements for phpinfo(). I wanna ask you if you consider it a feature and thus if I have to finish it before the first beta is released if I wanna include it in PHP7 or rather to target it against PHP 7.1. What is the benefit changing it? XHTML is a standard which is alive. But, there's for sure some code based on parsing the phpinfo() output, since not everything is exported as a constant. IMHO having HTML5 in phpinfo(), while being nice, doesn't justify itself breaking those codes. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On 06/28/2015 09:22 PM, Christoph Becker wrote:
Marc Bennewitz wrote:
On 06/25/2015 09:48 PM, Aaron Piotrowski wrote:
On Jun 25, 2015, at 2:39 PM, Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin wrote:
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current
behavior;
http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined
function Foo::()
This behavior is inconsistent!
Thanks
Marc
Interesting, I didn’t consider that an empty method name should invoke
__callStatic(). I’ll look into fixing this sometime today or tomorrow.
Is this edge case addressed now?
My PR has been closed now where this edge case was addressed, too.
That is supposed to be addressed by
http://git.php.net/?p=php-src.git;a=commit;h=ba67fc221890aaa395912aefebb96155afe671c1.
Can you please confirm with a recent master? (The Windows snapshots
currently in build progress are likely to have this commit included, too.)
It's fixed now - Thanks! :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On 06/25/2015 09:48 PM, Aaron Piotrowski wrote:
On Jun 25, 2015, at 2:39 PM, Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin wrote:
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current
behavior;
http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined
function Foo::()
This behavior is inconsistent!
Thanks
Marc
Interesting, I didn’t consider that an empty method name should invoke
__callStatic(). I’ll look into fixing this sometime today or tomorrow.
Is this edge case addressed now?
My PR has been closed now where this edge case was addressed, too.
Thanks,
Aaron Piotrowski
Thanks
Marc
Re: [PHP-DEV] Headsup: PHP7 feature freeze
Marc Bennewitz wrote:
On 06/25/2015 09:48 PM, Aaron Piotrowski wrote:
On Jun 25, 2015, at 2:39 PM, Marc Bennewitz dev@mabe.berlin
mailto:dev@mabe.berlin wrote:
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current
behavior;
http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined
function Foo::()
This behavior is inconsistent!
Thanks
Marc
Interesting, I didn’t consider that an empty method name should invoke
__callStatic(). I’ll look into fixing this sometime today or tomorrow.
Is this edge case addressed now?
My PR has been closed now where this edge case was addressed, too.
That is supposed to be addressed by
http://git.php.net/?p=php-src.git;a=commit;h=ba67fc221890aaa395912aefebb96155afe671c1.
Can you please confirm with a recent master? (The Windows snapshots
currently in build progress are likely to have this commit included, too.)
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Headsup: PHP7 feature freeze
Hi, https://github.com/php/php-src/pull/1367 implements some additions to the zend_string API I'd like to see in 7.0. It's important, IMHO, because it provides macros to access the 'val' and 'len' fields of the zend_string struct, which didn't exist previously. Because of this, we already have thousands of locations directly accessing -val/-len. This will take a lot of time to fix and the first step is to provide an abstraction layer as soon as possible. I asked Dmitry to review the change. As we have a very short delay, I also announce it here to ensure anybody interested can give an opinion. Important: The PR only contains additional functions and macros. It is 100 % backwards compatible with any code using the zend_string API. Regards François -Message d'origine- De : kalle@gmail.com [mailto:kalle@gmail.com] De la part de Kalle Sommer Nielsen Envoyé : jeudi 25 juin 2015 17:04 À : Internals Cc : Anatoliy Belsky; Dmitry Stogov; Nikita Popov; Ferenc Kovacs; Xinchen Hui Objet : [PHP-DEV] Headsup: PHP7 feature freeze Howdy This is a quick heads up that we plan to have the next release of 7.0.0 be Beta 1, this marks a feature freeze and from there on, we will switch focus on to stabilization, regressions and other bug fixes. Beta 1 is schedule to be tagged and packaged on July 7th and released on July 9th which is a small 2 weeks from now to get any remaining changes of such in. If you are in doubt about whether or not your change would be considered a 'feature' or have any other questions, then feel free to mail us RMs or reply here. Thanks, Kalle, Anatol Ferenc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
Hi all, On Fri, Jun 26, 2015 at 12:56 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Hannes, On Fri, Jun 26, 2015 at 12:51 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Why do you think its undocumented? http://php.net/manual/en/sessionhandler.create-sid.php Rename discussion was there. And I explicitly discussed it's undocumented and it violates CODING_STANDARDS, but it was added recently (after the discussion I suppose). [yohgaki@dev session]$ svn log -r 334814 r334814 | aharvey | 2014-09-09 04:49:26 +0900 (2014年09月09日 (火)) | 2 lines Add documentation for SessionHandler::create_sid(). 334814aharvey classnameSessionHandler/classname is a special class that can be used 334814aharvey to expose the current internal PHP session save handler by inheritance. 334814aharvey There are seven methods which wrap the seven internal session save handler 334814aharvey callbacks (parameteropen/parameter, parameterclose/parameter, 334814aharvey parameterread/parameter, parameterwrite/parameter, 334814aharvey parameterdestroy/parameter, parametergc/parameter and 334814aharvey parametercreate_sid/parameter). By default, this class will wrap 334814aharvey whatever internal save handler is set as defined by the 334814aharvey link linkend=ini.session.save-handlersession.save_handler/link 334814aharvey configuration directive which is usually parameterfiles/parameter by 334814aharvey default. Other internal session save handlers are provided by PHP 334814aharvey extensions such as SQLite (as parametersqlite/parameter), Memcache (as 334814aharvey parametermemcache/parameter), and Memcached (as 334814aharvey parametermemcached/parameter). I think this should be reverted. Or it may stay there. It's just a matter of having a copy of create_sid(). I'll add documentation. I forgot that session_create_id() is needed createSid() method to be more useful. The code for session_create_id() is in the source, but it isn't enabled. I wouldn't like to have different naming session_create_id() and createSid(). So I would like to have - session_create_id() function - createId() function because there is - session_id() since PHP4. I don't think session internal names do not have to be changed. i.e. Macros, etc. Any comments? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On Fri, Jun 26, 2015 at 8:57 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I don't think session internal names do not have to be changed. I meant I think session internal names do not have to be changed. I don't mind at all cleanup them. -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Headsup: PHP7 feature freeze
Marc Bennewitz wrote: I would really like to see directly calling a string of Class::method be fixed for 7.0. It's currently resulting in a fatal error and is inconsistent with call_user_func[_array], is_callable and the callable type-hint. There is also a PR open since April 2014 : https://github.com/php/php-src/pull/659 Apparently, your PR has been overlooked, but it seems this is already implemented as result of merging PR #1264[1]; see http://3v4l.org/W8hQA. Can you please verify, and close your PR #659 as appropriate. [1] https://github.com/php/php-src/pull/1264 -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On 06/25/2015 09:31 PM, Christoph Becker wrote:
Marc Bennewitz wrote:
I would really like to see directly calling a string of Class::method
be fixed for 7.0.
It's currently resulting in a fatal error and is inconsistent with
call_user_func[_array], is_callable and the callable type-hint.
There is also a PR open since April 2014 :
https://github.com/php/php-src/pull/659
Apparently, your PR has been overlooked, but it seems this is already
implemented as result of merging PR #1264[1]; see
http://3v4l.org/W8hQA. Can you please verify, and close your PR #659
as appropriate.
[1] https://github.com/php/php-src/pull/1264
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current behavior;
http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined function
Foo::()
This behavior is inconsistent!
Thanks
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On Jun 25, 2015, at 2:08 PM, Marc Bennewitz dev@mabe.berlin wrote: I would really like to see directly calling a string of Class::method be fixed for 7.0. It's currently resulting in a fatal error and is inconsistent with call_user_func[_array], is_callable and the callable type-hint. There is also a PR open since April 2014 : https://github.com/php/php-src/pull/659 Actually this has already been fixed for PHP 7, see this commit: https://github.com/php/php-src/commit/07ecfc7ba9dabc4dfb2a068744b76540308b Thanks, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On 06/25/2015 09:39 PM, Marc Bennewitz wrote:
On 06/25/2015 09:31 PM, Christoph Becker wrote:
Marc Bennewitz wrote:
I would really like to see directly calling a string of Class::method
be fixed for 7.0.
It's currently resulting in a fatal error and is inconsistent with
call_user_func[_array], is_callable and the callable type-hint.
There is also a PR open since April 2014 :
https://github.com/php/php-src/pull/659
Apparently, your PR has been overlooked, but it seems this is already
implemented as result of merging PR #1264[1]; see
http://3v4l.org/W8hQA. Can you please verify, and close your PR #659
as appropriate.
[1] https://github.com/php/php-src/pull/1264
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current
behavior;
http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined
function Foo::()
This behavior is inconsistent!
Thanks
Marc
It's also inconsistent with $callable = ['Foo', ''];
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On Jun 25, 2015, at 2:39 PM, Marc Bennewitz dev@mabe.berlin wrote:
Nice to see this - didn't noted it in the last month :)
But there is one edge case that is not handled by PHP-7 at current behavior;
http://3v4l.org/HkRQ7 http://3v4l.org/HkRQ7
class Foo {
public static function __callStatic($m, $args) {
var_dump($m);
}
public function __call($m, $args) {
var_dump($m);
}
}
$callable = [new Foo, ''];
$callable(); // string(0)
$callable = 'Foo::';
$callable(); // Fatal error: Uncaught Error: Call to undefined function
Foo::()
This behavior is inconsistent!
Thanks
Marc
Interesting, I didn’t consider that an empty method name should invoke
__callStatic(). I’ll look into fixing this sometime today or tomorrow.
Thanks,
Aaron Piotrowski
[PHP-DEV] Headsup: PHP7 feature freeze
Howdy This is a quick heads up that we plan to have the next release of 7.0.0 be Beta 1, this marks a feature freeze and from there on, we will switch focus on to stabilization, regressions and other bug fixes. Beta 1 is schedule to be tagged and packaged on July 7th and released on July 9th which is a small 2 weeks from now to get any remaining changes of such in. If you are in doubt about whether or not your change would be considered a 'feature' or have any other questions, then feel free to mail us RMs or reply here. Thanks, Kalle, Anatol Ferenc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On 06/25/2015 05:03 PM, Kalle Sommer Nielsen wrote: Howdy This is a quick heads up that we plan to have the next release of 7.0.0 be Beta 1, this marks a feature freeze and from there on, we will switch focus on to stabilization, regressions and other bug fixes. Beta 1 is schedule to be tagged and packaged on July 7th and released on July 9th which is a small 2 weeks from now to get any remaining changes of such in. If you are in doubt about whether or not your change would be considered a 'feature' or have any other questions, then feel free to mail us RMs or reply here. I would really like to see directly calling a string of Class::method be fixed for 7.0. It's currently resulting in a fatal error and is inconsistent with call_user_func[_array], is_callable and the callable type-hint. There is also a PR open since April 2014 : https://github.com/php/php-src/pull/659 Thanks, Kalle, Anatol Ferenc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Headsup: PHP7 feature freeze
Hi Hannes, On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Why do you think its undocumented? http://php.net/manual/en/sessionhandler.create-sid.php Rename discussion was there. And I explicitly discussed it's undocumented and it violates CODING_STANDARDS, but it was added recently (after the discussion I suppose). [yohgaki@dev session]$ svn log -r 334814 r334814 | aharvey | 2014-09-09 04:49:26 +0900 (2014年09月09日 (火)) | 2 lines Add documentation for SessionHandler::create_sid(). 334814aharvey classnameSessionHandler/classname is a special class that can be used 334814aharvey to expose the current internal PHP session save handler by inheritance. 334814aharvey There are seven methods which wrap the seven internal session save handler 334814aharvey callbacks (parameteropen/parameter, parameterclose/parameter, 334814aharvey parameterread/parameter, parameterwrite/parameter, 334814aharvey parameterdestroy/parameter, parametergc/parameter and 334814aharvey parametercreate_sid/parameter). By default, this class will wrap 334814aharvey whatever internal save handler is set as defined by the 334814aharvey link linkend=ini.session.save-handlersession.save_handler/link 334814aharvey configuration directive which is usually parameterfiles/parameter by 334814aharvey default. Other internal session save handlers are provided by PHP 334814aharvey extensions such as SQLite (as parametersqlite/parameter), Memcache (as 334814aharvey parametermemcache/parameter), and Memcached (as 334814aharvey parametermemcached/parameter). I think this should be reverted. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Headsup: PHP7 feature freeze
Hi Hannes, On Fri, Jun 26, 2015 at 12:51 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Why do you think its undocumented? http://php.net/manual/en/sessionhandler.create-sid.php Rename discussion was there. And I explicitly discussed it's undocumented and it violates CODING_STANDARDS, but it was added recently (after the discussion I suppose). [yohgaki@dev session]$ svn log -r 334814 r334814 | aharvey | 2014-09-09 04:49:26 +0900 (2014年09月09日 (火)) | 2 lines Add documentation for SessionHandler::create_sid(). 334814aharvey classnameSessionHandler/classname is a special class that can be used 334814aharvey to expose the current internal PHP session save handler by inheritance. 334814aharvey There are seven methods which wrap the seven internal session save handler 334814aharvey callbacks (parameteropen/parameter, parameterclose/parameter, 334814aharvey parameterread/parameter, parameterwrite/parameter, 334814aharvey parameterdestroy/parameter, parametergc/parameter and 334814aharvey parametercreate_sid/parameter). By default, this class will wrap 334814aharvey whatever internal save handler is set as defined by the 334814aharvey link linkend=ini.session.save-handlersession.save_handler/link 334814aharvey configuration directive which is usually parameterfiles/parameter by 334814aharvey default. Other internal session save handlers are provided by PHP 334814aharvey extensions such as SQLite (as parametersqlite/parameter), Memcache (as 334814aharvey parametermemcache/parameter), and Memcached (as 334814aharvey parametermemcached/parameter). I think this should be reverted. Or it may stay there. It's just a matter of having a copy of create_sid(). I'll add documentation. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Headsup: PHP7 feature freeze
Hi all, On Fri, Jun 26, 2015 at 12:03 AM, Kalle Sommer Nielsen ka...@php.net wrote: This is a quick heads up that we plan to have the next release of 7.0.0 be Beta 1, this marks a feature freeze and from there on, we will switch focus on to stabilization, regressions and other bug fixes. Beta 1 is schedule to be tagged and packaged on July 7th and released on July 9th which is a small 2 weeks from now to get any remaining changes of such in. If you are in doubt about whether or not your change would be considered a 'feature' or have any other questions, then feel free to mail us RMs or reply here. I would like to rename _undocumented_ method name in Session module. http://php.net/manual/en/book.session.php The line is this. https://github.com/php/php-src/blob/master/ext/session/php_session.h#L334 create_sid() method should be createSid(). If some users used it, all they have to do is define copy of create_sid() method and compatibility is kept. Any comments? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Headsup: PHP7 feature freeze
On Thu, Jun 25, 2015 at 6:42 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Fri, Jun 26, 2015 at 12:03 AM, Kalle Sommer Nielsen ka...@php.net wrote: This is a quick heads up that we plan to have the next release of 7.0.0 be Beta 1, this marks a feature freeze and from there on, we will switch focus on to stabilization, regressions and other bug fixes. Beta 1 is schedule to be tagged and packaged on July 7th and released on July 9th which is a small 2 weeks from now to get any remaining changes of such in. If you are in doubt about whether or not your change would be considered a 'feature' or have any other questions, then feel free to mail us RMs or reply here. I would like to rename _undocumented_ method name in Session module. http://php.net/manual/en/book.session.php The line is this. https://github.com/php/php-src/blob/master/ext/session/php_session.h#L334 create_sid() method should be createSid(). If some users used it, all they have to do is define copy of create_sid() method and compatibility is kept. Any comments? Why do you think its undocumented? http://php.net/manual/en/sessionhandler.create-sid.php -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
