Headsup: PHP7 feature freeze

10 years ago by Marc Bennewitz — view source

unread

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

10 years ago by Christoph Becker — view source

unread

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

10 years ago by Marc Bennewitz — view source

unread

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

10 years ago by Marc Bennewitz — view source

unread

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', ''];

10 years ago by Aaron Piotrowski — view source

unread

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

9 years ago by Marc Bennewitz — view source

unread

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

9 years ago by Christoph Becker — view source

unread

Marc Bennewitz 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

9 years ago by Marc Bennewitz — view source

unread

Marc Bennewitz 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! :)

10 years ago by Aaron Piotrowski — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

Hi all,

On Fri, Jun 26, 2015 at 12:03 AM, Kalle Sommer Nielsen kalle@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
yohgaki@ohgaki.net

10 years ago by Hannes Magnusson — view source

unread

Hi all,

On Fri, Jun 26, 2015 at 12:03 AM, Kalle Sommer Nielsen kalle@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

9 years ago by Yasuo Ohgaki — view source

unread

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 <classname>SessionHandler</classname> 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 (<parameter>open</parameter>,
<parameter>close</parameter>,
334814 aharvey <parameter>read</parameter>,
<parameter>write</parameter>,
334814 aharvey <parameter>destroy</parameter>,
<parameter>gc</parameter> and
334814 aharvey <parameter>create_sid</parameter>). By default, this
class will wrap
334814 aharvey whatever internal save handler is set as defined by
the
334814 aharvey <link linkend="ini.session.save-handler">session.save_handler</link>
334814 aharvey configuration directive which is usually
<parameter>files</parameter> by
334814 aharvey default. Other internal session save handlers are
provided by PHP
334814 aharvey extensions such as SQLite (as
<parameter>sqlite</parameter>), Memcache (as
334814 aharvey <parameter>memcache</parameter>), and Memcached (as
334814 aharvey <parameter>memcached</parameter>).

I think this should be reverted.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Yasuo Ohgaki — view source

unread

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 <classname>SessionHandler</classname> 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 (<parameter>open</parameter>,
<parameter>close</parameter>,
334814 aharvey <parameter>read</parameter>,
<parameter>write</parameter>,
334814 aharvey <parameter>destroy</parameter>,
<parameter>gc</parameter> and
334814 aharvey <parameter>create_sid</parameter>). By default,
this class will wrap
334814 aharvey whatever internal save handler is set as defined by
the
334814 aharvey <link linkend="ini.session.save-handler">session.save_handler</link>
334814 aharvey configuration directive which is usually
<parameter>files</parameter> by
334814 aharvey default. Other internal session save handlers are
provided by PHP
334814 aharvey extensions such as SQLite (as
<parameter>sqlite</parameter>), Memcache (as
334814 aharvey <parameter>memcache</parameter>), and Memcached (as
334814 aharvey <parameter>memcached</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
yohgaki@ohgaki.net

9 years ago by Yasuo Ohgaki — view source

unread

Hi all,

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 <classname>SessionHandler</classname> 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 (<parameter>open</parameter>,
<parameter>close</parameter>,
334814 aharvey <parameter>read</parameter>,
<parameter>write</parameter>,
334814 aharvey <parameter>destroy</parameter>,
<parameter>gc</parameter> and
334814 aharvey <parameter>create_sid</parameter>). By default,
this class will wrap
334814 aharvey whatever internal save handler is set as defined by
the
334814 aharvey <link linkend="ini.session.save-handler">session.save_handler</link>
334814 aharvey configuration directive which is usually
<parameter>files</parameter> by
334814 aharvey default. Other internal session save handlers are
provided by PHP
334814 aharvey extensions such as SQLite (as
<parameter>sqlite</parameter>), Memcache (as
334814 aharvey <parameter>memcache</parameter>), and Memcached (as
334814 aharvey <parameter>memcached</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
yohgaki@ohgaki.net

9 years ago by Yasuo Ohgaki — view source

unread

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

9 years ago by Anatol Belski — view source

unread

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,

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 <classname>SessionHandler</classname> 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 (<parameter>open</parameter>,
<parameter>close</parameter>,
334814 aharvey <parameter>read</parameter>,
<parameter>write</parameter>,
334814 aharvey <parameter>destroy</parameter>,
<parameter>gc</parameter> and
334814 aharvey <parameter>create_sid</parameter>). By default,
this class will wrap
334814 aharvey whatever internal save handler is set as defined by
the
334814 aharvey <link linkend="ini.session.save-handler">session.save_handler</link>
334814 aharvey configuration directive which is usually
<parameter>files</parameter> by
334814 aharvey default. Other internal session save handlers are
provided by PHP
334814 aharvey extensions such as SQLite (as
<parameter>sqlite</parameter>), Memcache (as
334814 aharvey <parameter>memcache</parameter>), and Memcached
(as
334814 aharvey <parameter>memcached</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

9 years ago by Yasuo Ohgaki — view source

unread

Hi Anatol,

On Mon, Jun 29, 2015 at 10:19 PM, Anatol Belski anatol.php@belski.net
wrote:

-----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,

On Fri, Jun 26, 2015 at 12:56 PM, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:

Hi Hannes,

On Fri, Jun 26, 2015 at 12:51 PM, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:

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 <classname>SessionHandler</classname> 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 (<parameter>open</parameter>,
<parameter>close</parameter>,
334814 aharvey <parameter>read</parameter>,
<parameter>write</parameter>,
334814 aharvey <parameter>destroy</parameter>,
<parameter>gc</parameter> and
334814 aharvey <parameter>create_sid</parameter>). By default,
this class will wrap
334814 aharvey whatever internal save handler is set as
defined by
the
334814 aharvey <link linkend="ini.session.save-handler">session.save_handler</link>
334814 aharvey configuration directive which is usually
<parameter>files</parameter> by
334814 aharvey default. Other internal session save handlers
are
provided by PHP
334814 aharvey extensions such as SQLite (as
<parameter>sqlite</parameter>), Memcache (as
334814 aharvey <parameter>memcache</parameter>), and Memcached
(as
334814 aharvey <parameter>memcached</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
yohgaki@ohgaki.net

9 years ago by francois@php.net — view source

unread

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

9 years ago by kelerest123@gmail.com — view source

unread

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 kalle@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

9 years ago by Anatol Belski — view source

unread

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 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

9 years ago by kelerest123@gmail.com — view source

unread

2015-06-28 22:19 GMT+02:00 Anatol Belski anatol.php@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

9 years ago by Levi Morrison — view source

unread

2015-06-28 22:19 GMT+02:00 Anatol Belski anatol.php@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

9 years ago by Levi Morrison — view source

unread

2015-06-28 22:19 GMT+02:00 Anatol Belski anatol.php@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

--

(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.

9 years ago by Matt Wilmas — view source

unread

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

9 years ago by Anatol Belski — view source

unread

Hi Matt,

-----Original Message-----
From: Matt Wilmas [mailto:php_lists@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

9 years ago by Matt Wilmas — view source

unread

Hi Anatol,

----- Original Message -----
From: "Anatol Belski"
Sent: Monday, July 07, 2015

Hi Matt,

-----Original Message-----
From: Matt Wilmas [mailto:php_lists@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