Re: [PHP-DEV] PHP 8 next?

[Levi Morrison]

On Sat, Jun 23, 2018 at 3:23 PM Nikita Popov  wrote:
>
> Hi internals,
>
> Based on some recent conversations, I'm getting the impression that after
> PHP 7.3, we might want to go for PHP 8 next.
>
> I'd like to discuss and possibility decide this now, as that would make PHP
> 7.3 the last chance to get in deprecations.

I think this is an appropriate place to discuss these potential
deprecations. What ones do you specifically have in mind?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8 next?

[Kalle Sommer Nielsen]

Hi

Den søn. 24. jun. 2018 kl. 02.59 skrev Levi Morrison :
> Neither JIT nor FFI require backwards compatibility breaks in
> language. I don't think either of those particular features would
> substantially break the C API either. If these are the motivations for
> PHP 8 then I strongly object.

I agree with the objection, however they are also a major selling
point for a major version which I think is something worth keeping in
mind.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8 next?

[Levi Morrison]

On Sat, Jun 23, 2018 at 4:11 PM Zeev Suraski  wrote:
>
>
>
> > -Original Message-
> > From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> > Golemon
> > Sent: Sunday, June 24, 2018 1:07 AM
> > To: Nikita Popov 
> > Cc: PHP internals 
> > Subject: Re: [PHP-DEV] PHP 8 next?
> >
> > On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov  wrote:
> > > Based on some recent conversations, I'm getting the impression that
> > > after PHP 7.3, we might want to go for PHP 8 next.
> > >
> > > I'd like to discuss and possibility decide this now, as that would
> > > make PHP
> > > 7.3 the last chance to get in deprecations.
> > >
> > Would you mind elaborating on your motivations for a major version bump.  
> > I'm
> > not saying I disagree in principle, I'm just curious what you're seeing the 
> > drivers
> > as.
>
> This is slightly earlier than I intended to bring it up but I do too think 
> that the next version beyond 7.3 should be 8.
>
> I'll send a more detailed letter next week - but in a nutshell, the main 
> drivers I'm seeing are JIT, FFI and possibly doing something in the front of 
> async/long running processes.  Of course there may be other ones as well, but 
> I think that these alone constitute sufficient grounds for launching a new 
> major version.
>
> Zeev
>

Neither JIT nor FFI require backwards compatibility breaks in
language. I don't think either of those particular features would
substantially break the C API either. If these are the motivations for
PHP 8 then I strongly object.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8 next?

[Sara Golemon]

On Sat, Jun 23, 2018 at 5:11 PM, Zeev Suraski  wrote:
>> On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov  wrote:
>> > Based on some recent conversations, I'm getting the impression that
>> > after PHP 7.3, we might want to go for PHP 8 next.
>> >
>> > I'd like to discuss and possibility decide this now, as that would
>> > make PHP
>> > 7.3 the last chance to get in deprecations.
>> >
>> Would you mind elaborating on your motivations for a major version bump.  I'm
>> not saying I disagree in principle, I'm just curious what you're seeing the 
>> drivers
>> as.
>
> I'll send a more detailed letter next week - but in a nutshell, the main 
> drivers
> I'm seeing are JIT, FFI and possibly doing something in the front of
> async/long running processes.  Of course there may be other ones
> as well, but I think that these alone constitute sufficient grounds for
> launching a new major version.
>
Any one of JIT or async/long-running alone would be enough to merit
the bump, so yeah, I'm provisionally on board with that.  FFI is cool
and all, but it's also not really a major-bump-worthy feature.  I
didn't realize the JIT was to the point that it was showing real
promise.  Last update I'd heard was that it was academically
interesting, but underwhelming in practice.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8 next?

[Dustin Wheeler]

Hello, 

> On Jun 23, 2018, at 6:38 PM, Alice Wonder  wrote:
> 
>> On 06/23/2018 03:11 PM, Zeev Suraski wrote:
>> 
>> This is slightly earlier than I intended to bring it up but I do too think 
>> that the next version beyond 7.3 should be 8.
> 
> I disagree.
> 
> I'm mostly a user, not a PHP developer.
> 
> RHEL 7.5, the latest version of RHEL, still ships 5.4.
> 

RHEL has official software collections for PHP 7.0 and 7.1. Remi has an SCL for 
7.2. We run 7.2 in production and 5.6 is gone in December. 5.4.16 in RHEL 
was... a mistake. There is nothing “un-enterprise” about the SCLs and they work 
very well. 

RHEL 8 is coming soon and is based on Fedora 28. It will likely ship 7.2, I 
imagine. 

> Other LTS distributions also probably ship 5.x.
> 

Ubuntu 16.04 LTS shipped with PHP 7.0. Ubuntu 18.04 LTS ships with PHP 7.2. PHP 
5.* was a great line but it has been time to move for a while. It’s getting 
harder to come up with reasoning to stay. I haven’t come across a codebase that 
didn’t run on 7+ and this includes a 16 year old codebase that started on PHP 
4. It’s an anecdote, but proof that anything is possible. 

> So a major version bump now would mean three major versions of PHP that web 
> applications intended to "just work" on enterprise *nix would have to support.
> 

For sure, this is the distribution’s choice, not the maintainers here. 

> If there was a major design flaw in PHP that can only truly be fixed by an 
> incompatible version bump past 7 then do it but otherwise, I think it would 
> be better to wait until the most recent versions of enterprise distributions 
> have moved to php 7.
> 
> I'm hoping RHEL 8 does, the benefits are tremendous of 7 over 6.x, but...
> 
> The issue is some customers of enterprise linux specifically don't want 
> frankenstein systems and want to use vendor supported packages only, and I 
> can see their point of view because they pay a lot of money for that support.
> 
> That being said, I try to get everyone running old PHP up to 7.1 or 7.2 even 
> if it means frankenstein systems. But some think the benefit of enterprise 
> vendor support outweighs the improvements in PHP.

I have Puppet to manage LAMP using httpd24 and php72 on RHEL if you’re 
interested. Once it is in config management, it’s not “Frankenstein” anymore. 
And if folks complain about “Frankenstein” systems when their definition of 
such is using software collections, I would argue their not getting value out 
of the product provided by RedHat, as SCL versions of PHP are provided by the 
vendor! Use them!


-Dustin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8 next?

[Michael Morris]

On Sat, Jun 23, 2018 at 6:39 PM Alice Wonder  wrote:

> On 06/23/2018 03:11 PM, Zeev Suraski wrote:
> >
> >
> >> -Original Message-
> >> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> >> Golemon
> >> Sent: Sunday, June 24, 2018 1:07 AM
> >> To: Nikita Popov 
> >> Cc: PHP internals 
> >> Subject: Re: [PHP-DEV] PHP 8 next?
> >>
> >> On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov 
> wrote:
> >>> Based on some recent conversations, I'm getting the impression that
> >>> after PHP 7.3, we might want to go for PHP 8 next.
> >>>
> >>> I'd like to discuss and possibility decide this now, as that would
> >>> make PHP
> >>> 7.3 the last chance to get in deprecations.
> >>>
> >> Would you mind elaborating on your motivations for a major version
> bump.  I'm
> >> not saying I disagree in principle, I'm just curious what you're seeing
> the drivers
> >> as.
> >
> > This is slightly earlier than I intended to bring it up but I do too
> think that the next version beyond 7.3 should be 8.
>
> I disagree.
>
> I'm mostly a user, not a PHP developer.
>
> RHEL 7.5, the latest version of RHEL, still ships 5.4.
>
> Other LTS distributions also probably ship 5.x.
>
> So a major version bump now would mean three major versions of PHP that
> web applications intended to "just work" on enterprise *nix would have
> to support.
>
> If there was a major design flaw in PHP that can only truly be fixed by
> an incompatible version bump past 7 then do it but otherwise, I think it
> would be better to wait until the most recent versions of enterprise
> distributions have moved to php 7.
>
> I'm hoping RHEL 8 does, the benefits are tremendous of 7 over 6.x, but...
>
> The issue is some customers of enterprise linux specifically don't want
> frankenstein systems and want to use vendor supported packages only, and
> I can see their point of view because they pay a lot of money for that
> support.
>
> That being said, I try to get everyone running old PHP up to 7.1 or 7.2
> even if it means frankenstein systems. But some think the benefit of
> enterprise vendor support outweighs the improvements in PHP.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/ 

unsub.php 



If we’re going to 8 can we please fix the ternary operator now???

> 
>
>

Re: [PHP-DEV] PHP 8 next?

[Alice Wonder]

On 06/23/2018 03:11 PM, Zeev Suraski wrote:




-Original Message-
From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
Golemon
Sent: Sunday, June 24, 2018 1:07 AM
To: Nikita Popov 
Cc: PHP internals 
Subject: Re: [PHP-DEV] PHP 8 next?

On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov  wrote:

Based on some recent conversations, I'm getting the impression that
after PHP 7.3, we might want to go for PHP 8 next.

I'd like to discuss and possibility decide this now, as that would
make PHP
7.3 the last chance to get in deprecations.


Would you mind elaborating on your motivations for a major version bump.  I'm
not saying I disagree in principle, I'm just curious what you're seeing the 
drivers
as.


This is slightly earlier than I intended to bring it up but I do too think that 
the next version beyond 7.3 should be 8.


I disagree.

I'm mostly a user, not a PHP developer.

RHEL 7.5, the latest version of RHEL, still ships 5.4.

Other LTS distributions also probably ship 5.x.

So a major version bump now would mean three major versions of PHP that 
web applications intended to "just work" on enterprise *nix would have 
to support.


If there was a major design flaw in PHP that can only truly be fixed by 
an incompatible version bump past 7 then do it but otherwise, I think it 
would be better to wait until the most recent versions of enterprise 
distributions have moved to php 7.


I'm hoping RHEL 8 does, the benefits are tremendous of 7 over 6.x, but...

The issue is some customers of enterprise linux specifically don't want 
frankenstein systems and want to use vendor supported packages only, and 
I can see their point of view because they pay a lot of money for that 
support.


That being said, I try to get everyone running old PHP up to 7.1 or 7.2 
even if it means frankenstein systems. But some think the benefit of 
enterprise vendor support outweighs the improvements in PHP.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP 8 next?

[Zeev Suraski]

> -Original Message-
> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Sunday, June 24, 2018 1:07 AM
> To: Nikita Popov 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] PHP 8 next?
> 
> On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov  wrote:
> > Based on some recent conversations, I'm getting the impression that
> > after PHP 7.3, we might want to go for PHP 8 next.
> >
> > I'd like to discuss and possibility decide this now, as that would
> > make PHP
> > 7.3 the last chance to get in deprecations.
> >
> Would you mind elaborating on your motivations for a major version bump.  I'm
> not saying I disagree in principle, I'm just curious what you're seeing the 
> drivers
> as.

This is slightly earlier than I intended to bring it up but I do too think that 
the next version beyond 7.3 should be 8.

I'll send a more detailed letter next week - but in a nutshell, the main 
drivers I'm seeing are JIT, FFI and possibly doing something in the front of 
async/long running processes.  Of course there may be other ones as well, but I 
think that these alone constitute sufficient grounds for launching a new major 
version. 

Zeev

Re: [PHP-DEV] PHP 8 next?

[Sara Golemon]

On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov  wrote:
> Based on some recent conversations, I'm getting the impression that after
> PHP 7.3, we might want to go for PHP 8 next.
>
> I'd like to discuss and possibility decide this now, as that would make PHP
> 7.3 the last chance to get in deprecations.
>
Would you mind elaborating on your motivations for a major version
bump.  I'm not saying I disagree in principle, I'm just curious what
you're seeing the drivers as.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 8 next?

[Nikita Popov]

Hi internals,

Based on some recent conversations, I'm getting the impression that after
PHP 7.3, we might want to go for PHP 8 next.

I'd like to discuss and possibility decide this now, as that would make PHP
7.3 the last chance to get in deprecations.

Nikita

Re: [PHP-DEV] Re: memcache, without a d, as in Venezuela

[AllenJB]

Someone was asking about memcache vs memached on IRC the other day and I 
advised them the memcache extension looked abandoned based on the PECL 
page. Having 2 such similar extensions is confusing - It would also be 
nice if someone could document the major differences between the 2 
extensions somewhere to help users decide which they might want to select.


Remi mentioned over on the PECL list that the memcached extension relies 
on a library that's been abandoned since 2014 ( 
http://news.php.net/php.pecl.dev/15377 )


The websupport-sk 'memcache' repository is not linked to or mentioned on 
the pecl.php.net project page as far as I can see.


The documentation for 'memcache' on the php.net manual (linked from the 
documentation link on PECL) is not for the websupport-sk version - the 
readme on the websupport-sk repo mentions a "new API in 3.0" that uses a 
MemcachePool class which doesn't appear on the php.net documentation. I 
suspect it's likely there are other differences.


It looks like Pierre has been in discussion about merging/moving the 
websupport-sk repo back to PECL but progress appears to be slow / 
stalled - perhaps someone could prod Pierre or take up the reigns on 
this: https://github.com/websupport-sk/pecl-memcache/issues/4


At the very least if someone could add a header or obvious link to the 
pecl.php.net page and manual pointing to the websupport-sk project, that 
would help users in the mean time.


AllenJB

On 23/06/2018 15:16, Jan Ehrhardt wrote:

Rowan Collins in php.internals (Fri, 22 Jun 2018 23:40:27 +0100):

However, it seems that the package without a d is actually abandoned.
The official PECL package was last released more than 5 years ago [3],
and the bug asking for PHP 7 compatibility is still open [4]. An
unofficial fork apparently supports PHP 7 [5] but it in turn hasn't had
a commit in 11 months, and has an open bug for 7.2 compatibility [6].

It has some PR's, even a recent one by Remi Collet for 7.3
compatibility.
https://github.com/websupport-sk/pecl-memcache/pull/30

The open bug for 7.2 compatibility seems to be open only because nobody
bothered to close it.


- Is there any difference, other than API design, between the two
packages, which would merit seeking a new maintainer for memcache
(without a d)?

The package without a d is AFAIK the only one that runs on Windows:
https://github.com/websupport-sk/pecl-memcache/issues/23#issuecomment-358956029
Client & server updates by 'nono303':
https://www.apachelounge.com/viewtopic.php?t=7919
https://github.com/nono303/PHP7-memcache-dll


- If not, should the package be officially marked "abandoned" or
"deprecated" in PECL, and in the PHP manual?

That would not be a good solution for the (few) Windows users.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: memcache, without a d, as in Venezuela

[Jan Ehrhardt]

Rowan Collins in php.internals (Fri, 22 Jun 2018 23:40:27 +0100):
>However, it seems that the package without a d is actually abandoned. 
>The official PECL package was last released more than 5 years ago [3], 
>and the bug asking for PHP 7 compatibility is still open [4]. An 
>unofficial fork apparently supports PHP 7 [5] but it in turn hasn't had 
>a commit in 11 months, and has an open bug for 7.2 compatibility [6].

It has some PR's, even a recent one by Remi Collet for 7.3
compatibility.
https://github.com/websupport-sk/pecl-memcache/pull/30

The open bug for 7.2 compatibility seems to be open only because nobody
bothered to close it.

>- Is there any difference, other than API design, between the two 
>packages, which would merit seeking a new maintainer for memcache 
>(without a d)?

The package without a d is AFAIK the only one that runs on Windows:
https://github.com/websupport-sk/pecl-memcache/issues/23#issuecomment-358956029
Client & server updates by 'nono303':
https://www.apachelounge.com/viewtopic.php?t=7919
https://github.com/nono303/PHP7-memcache-dll

>- If not, should the package be officially marked "abandoned" or 
>"deprecated" in PECL, and in the PHP manual?

That would not be a good solution for the (few) Windows users.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php