# Headsup: PHP7 feature freeze - Thread: https://externals.io/message/86869 - Original archive: https://news-web.php.net/php.internals/86869 - Started by Kalle Sommer Nielsen on 2015-06-25T15:03:31+00:00 - Messages: 27 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/86869.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #86869 — Kalle Sommer Nielsen — 2015-06-25T15:03:31+00:00 URL: https://externals.io/message/86869#86869 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 --- ## #86878 — Marc Bennewitz — 2015-06-25T19:08:58+00:00 URL: https://externals.io/message/86869#86878 · In reply to: #86869 > 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 --- ## #86879 — Christoph Becker — 2015-06-25T19:31:17+00:00 URL: https://externals.io/message/86869#86879 · In reply to: #86878 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 . Can you please verify, and close your PR #659 as appropriate. [1] -- Christoph M. Becker --- ## #86880 — Aaron Piotrowski — 2015-06-25T19:31:24+00:00 URL: https://externals.io/message/86869#86880 · In reply to: #86878 > > > 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/071111ecfc7ba9dabc4dfb2a068744b76540308b Thanks, Aaron Piotrowski --- ## #86881 — Marc Bennewitz — 2015-06-25T19:39:21+00:00 URL: https://externals.io/message/86869#86881 · In reply to: #86879 > Marc Bennewitz wrote: > > > […] > Apparently, your PR has been overlooked, but it seems this is already > implemented as result of merging PR #1264[1]; see > . Can you please verify, and close your PR #659 > as appropriate. > > [1] > 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 --- ## #86882 — Marc Bennewitz — 2015-06-25T19:41:43+00:00 URL: https://externals.io/message/86869#86882 · In reply to: #86881 > > > > > […] > > 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', '']; --- ## #86883 — Aaron Piotrowski — 2015-06-25T19:48:52+00:00 URL: https://externals.io/message/86869#86883 · In reply to: #86881 > > > 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. Thanks, Aaron Piotrowski --- ## #86890 — Yasuo Ohgaki — 2015-06-26T01:42:04+00:00 URL: https://externals.io/message/86869#86890 · In reply to: #86869 Hi all, On Fri, Jun 26, 2015 at 12:03 AM, Kalle Sommer Nielsen 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 yohgaki@ohgaki.net --- ## #86891 — Hannes Magnusson — 2015-06-26T01:48:13+00:00 URL: https://externals.io/message/86869#86891 · In reply to: #86890 > Hi all, > > On Fri, Jun 26, 2015 at 12:03 AM, Kalle Sommer Nielsen > wrote: > > > […] > > 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 --- ## #86892 — Yasuo Ohgaki — 2015-06-26T03:51:47+00:00 URL: https://externals.io/message/86869#86892 · In reply to: #86891 Hi Hannes, On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson < hannes.magnusson@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(). ------------------------------------------------------------------------ 334814 aharvey SessionHandler is a special class that can be used 334814 aharvey to expose the current internal PHP session save handler by inheritance. 334814 aharvey There are seven methods which wrap the seven internal session save handler 334814 aharvey callbacks (open, close, 334814 aharvey read, write, 334814 aharvey destroy, gc and 334814 aharvey create_sid). By default, this class will wrap 334814 aharvey whatever internal save handler is set as defined by the 334814 aharvey session.save_handler 334814 aharvey configuration directive which is usually files by 334814 aharvey default. Other internal session save handlers are provided by PHP 334814 aharvey extensions such as SQLite (as sqlite), Memcache (as 334814 aharvey memcache), and Memcached (as 334814 aharvey memcached). I think this should be reverted. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #86893 — Yasuo Ohgaki — 2015-06-26T03:56:18+00:00 URL: https://externals.io/message/86869#86893 · In reply to: #86892 Hi Hannes, > On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson < > hannes.magnusson@gmail.com> wrote: > > > […] > > 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(). > > ------------------------------------------------------------------------ > > 334814 aharvey SessionHandler is a special > class that can be used > 334814 aharvey to expose the current internal PHP session save > handler by inheritance. > 334814 aharvey There are seven methods which wrap the seven > internal session save handler > 334814 aharvey callbacks (open, > close, > 334814 aharvey read, > write, > 334814 aharvey destroy, > gc and > 334814 aharvey create_sid). By default, > this class will wrap > 334814 aharvey whatever internal save handler is set as defined by > the > 334814 aharvey linkend="ini.session.save-handler">session.save_handler > 334814 aharvey configuration directive which is usually > files by > 334814 aharvey default. Other internal session save handlers are > provided by PHP > 334814 aharvey extensions such as SQLite (as > sqlite), Memcache (as > 334814 aharvey memcache), and Memcached (as > 334814 aharvey memcached). > > 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 yohgaki@ohgaki.net --- ## #86912 — francois@php.net — 2015-06-26T11:35:50+00:00 URL: https://externals.io/message/86869#86912 · In reply to: #86869 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.php@gmail.com [mailto:kalle.php@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 --- ## #86913 — Yasuo Ohgaki — 2015-06-26T11:57:43+00:00 URL: https://externals.io/message/86869#86913 · In reply to: #86893 Hi all, > Hi Hannes, > > > > > […] > > 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 yohgaki@ohgaki.net --- ## #86914 — Yasuo Ohgaki — 2015-06-26T12:04:53+00:00 URL: https://externals.io/message/86869#86914 · In reply to: #86913 > 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 yohgaki@ohgaki.net --- ## #86924 — kelerest123@gmail.com — 2015-06-28T14:03:04+00:00 URL: https://externals.io/message/86869#86924 · In reply to: #86869 Hi RMs, I have a pending change here 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 : > 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 --- ## #86927 — Marc Bennewitz — 2015-06-28T19:02:21+00:00 URL: https://externals.io/message/86869#86927 · In reply to: #86883 > > > […] > > 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 --- ## #86928 — Christoph Becker — 2015-06-28T19:22:40+00:00 URL: https://externals.io/message/86869#86928 · In reply to: #86927 Marc Bennewitz wrote: > > > […] > > 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 . 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 --- ## #86929 — Anatol Belski — 2015-06-28T20:19:51+00:00 URL: https://externals.io/message/86869#86929 · In reply to: #86924 Hi Jakub, > -----Original Message----- > From: Jakub Kubíček [mailto:kelerest123@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 > 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 --- ## #86930 — Marc Bennewitz — 2015-06-28T20:23:51+00:00 URL: https://externals.io/message/86869#86930 · In reply to: #86928 > Marc Bennewitz wrote: > > > […] > That is supposed to be addressed by > . > 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! :) --- ## #86938 — Anatol Belski — 2015-06-29T13:19:44+00:00 URL: https://externals.io/message/86869#86938 · In reply to: #86913 Hi Yasuo, > -----Original Message----- > From: yohgaki@gmail.com [mailto:yohgaki@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, > > > > > […] > (as > > […] > > 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 --- ## #86948 — Yasuo Ohgaki — 2015-06-29T21:37:25+00:00 URL: https://externals.io/message/86869#86948 · In reply to: #86938 Hi Anatol, On Mon, Jun 29, 2015 at 10:19 PM, Anatol Belski wrote: > > […] > Nikita > > […] > wrote: > > […] > wrote: > > […] > special > > […] > defined by > > […] > are > > […] > createSid(). > > […] > 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 yohgaki@ohgaki.net --- ## #86949 — kelerest123@gmail.com — 2015-06-29T21:47:35+00:00 URL: https://externals.io/message/86869#86949 · In reply to: #86929 2015-06-28 22:19 GMT+02:00 Anatol Belski : > 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 or 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 --- ## #86961 — Levi Morrison — 2015-06-30T05:31:55+00:00 URL: https://externals.io/message/86869#86961 · In reply to: #86949 > 2015-06-28 22:19 GMT+02:00 Anatol Belski : > > […] > > That's on every person's opinion. XHTML is currently not a standard, > XHTML is dead. > > > […] > > Okay, that could be an argument. So I will rather focus on replacing > just these completely legacy things like or 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 --- ## #86962 — Levi Morrison — 2015-06-30T05:34:51+00:00 URL: https://externals.io/message/86869#86962 · In reply to: #86961 > > > […] (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. --- ## #87060 — Matt Wilmas — 2015-07-07T02:10:20+00:00 URL: https://externals.io/message/86869#87060 · In reply to: #86869 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 --- Next page: https://externals.io/message/86869.md?page=2