Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

[Mike Schinkel]

 
 
 
 
>  
> On Nov 21, 2023 at 11:33 PM,  mailto:george.bany...@gmail.com)>  
> wrote:
>  
>  
>  
>  What is the point of a major release if we cannot even do such a BC break? 
> We don't even know when PHP 9.0 is going to happen yet. 
>
>  
 
 

 
I have been using Go for about four years now and it seems they have gotten the 
backward compatibility issue nailed, and that pays great dividends in developer 
confidence in the language, i.e.:
 

 
 
https://www.reddit.com/r/golang/comments/17v4xja/anyone_face_issues_when_updating_version_of_go/
 

 
They recently explained in depth how they do it:
 

 
https://go.dev/blog/compat
 

 
Also see:
 

 
 https://thenewstack.io/how-golang-evolves-without-breaking-programs/
   

 
Although Go is compiled and PHP is not, I think there still may be significant 
insight that can be gained for PHP by studying how Go is handling it and 
applying any lessons learned.
 

 
#fwiw
 

 
- Mike
 

 

 

 

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

[Aleksander Machniak]

On 12.11.2023 17:47, Máté Kocsis wrote:

Link: https://wiki.php.net/rfc/resource_to_object_conversion


Is "Primary stream-related resources" section about file pointers? I'd 
like it to be more clear. Maybe it should even list all functions that 
will be impacted. I don't see an impact analysis for this section either.


--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

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

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

[G. P. B.]

On Thu, 16 Nov 2023 at 16:13, Jakub Zelenka  wrote:

> On Sun, Nov 12, 2023 at 4:48 PM Máté Kocsis 
> wrote:
>
> > Hi Internals,
> >
> > Following my straw poll about the Process resource name, I would like to
> > present an RFC which clarifies the rough timeline and the BC promises of
> > the "resource to object conversion" project.
> >
> > Link: https://wiki.php.net/rfc/resource_to_object_conversion
> >
> >
> Please could you add a separate vote for primary streams if the resource to
> object conversion should be done at all (requiring 2/3 votes to be
> accepted). I will personally vote against this if there is no is_resource
> change as I think it's just too big BC break even for 9.0 - it will likely
> require massive update of many code bases.
>

What is the point of a major release if we cannot even do such a BC break?
We don't even know when PHP 9.0 is going to happen yet.

I will also state that I am against changing the semantics of is_resource()
*unless* we remove support for resources altogether from the engine at the
same time so that there is no possible ambiguity.
Which frankly is probably something we should be doing, and that people
paid by the foundation should convert resources to opaque objects in PECL
extensions, and other extensions brought to our attention.
And yes, that also means helping Oracle with OCI8 that is getting unbundled.

I will try to get round to do ext/dba somewhat soon.

Best regards,

Gina P. Banyard

Re: [PHP-DEV] PHP-8.1 open for bug fixes UNTIL 25 Nov

[Ben Ramsey]

> On Nov 21, 2023, at 18:22, G. P. B.  wrote:
> 
> On Tue, 21 Nov 2023 at 21:10, Ben Ramsey  > wrote:
>> We’ve discussed this among release managers, and I’m updating this 
>> thread to clarify that I was mistaken about what the dates for supported 
>> versions mean. These are the dates up until we will accept patches to a 
>> version branch. So, for example, we will accept bug fix patches in the 
>> PHP-8.1 version branch until 25 November. This means there may be 
>> another release following the end-of-active-support date, if there are 
>> bug fixes in the version branch.
>> 
>> The PHP-8.1 branch is open for bug fixes UNTIL 25 November. I’m very 
>> sorry for the confusion.
>> 
>> Cheers,
>> Ben
> 
> Does this mean any bug-fix merged into 8.2 already needs to be backported?
> Or will 8.1 RMs do this?
> 
> Best regards,
> 
> Gina P. Banyard
>  


Gina,

Since this was my mistake, I will help resolve this. Let me know what bug fixes 
would have otherwise gone into the PHP-8.1 branch, and I’ll take care of 
merging them.

Cheers,
Ben

Re: [PHP-DEV] PHP-8.1 open for bug fixes UNTIL 25 Nov

[G. P. B.]

On Tue, 21 Nov 2023 at 21:10, Ben Ramsey  wrote:

> We’ve discussed this among release managers, and I’m updating this
> thread to clarify that I was mistaken about what the dates for supported
> versions mean. These are the dates up until we will accept patches to a
> version branch. So, for example, we will accept bug fix patches in the
> PHP-8.1 version branch until 25 November. This means there may be
> another release following the end-of-active-support date, if there are
> bug fixes in the version branch.
>
> The PHP-8.1 branch is open for bug fixes UNTIL 25 November. I’m very
> sorry for the confusion.
>
> Cheers,
> Ben
>

Does this mean any bug-fix merged into 8.2 already needs to be backported?
Or will 8.1 RMs do this?

Best regards,

Gina P. Banyard

Re: [PHP-DEV] RFC Proposal - static modifier for classes

[David Gebler]

I wouldn't support this, personally. I'm not a voter but I mean just in
terms of gauging community feel about the proposal, without unnecessarily
repeating what's already been said I just want to register that I'm in
agreement with Larry and Kamil's comments.

What static classes would achieve goes against the design principles of
what a class is and what it's for. Others have noted we already have an
adequate namespacing system and via Composer which is a de facto standard
in almost all PHP projects today, a means to autoload namespaced functions.

But more than that, I think for me - look, I get a lot of language features
which are sincerely useful can be argued to be just convenient syntax sugar
for things you could technically already do another way. But when I
consider features like readonly properties, constructor promotion and
readonly classes, I think the functional change goes beyond just syntax
sugar. You're getting an enormous saving versus say, trying to make a class
with all properties readonly in PHP 7.4. It's not just a little bit of
boilerplate trimmed down, it's you now have to write one line of code
instead of fifty.

So even if I supported the idea of static classes in principle, I'd still
be looking at it and thinking really the only convenience, the only syntax
sugar here is that you now have to type the word static N-1 fewer times
where N is the number of properties and functions in your class. This is
not a huge benefit or saving to me. While I wouldn't encourage anyone to
design their code this way, for the same reasons Larry has articulated, if
you want to design your code this way you already can at basically the same
cost of your time and effort and same cost to the PHP engine.

I think there'd need to be some persuasively more substantial gain for
either the developer or the execution of a script for this proposal to be
worth anything.

Thanks.

-David

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

[Máté Kocsis]

Hi Derick, Jakub, Phiip


> Did you do an analyses as to how much either of these changes could break
> anything?


I updated the RFC with some impact analysis. The numbers support my
hypothesis that the conversion
of auxiliary stream resources would cause hardly any BC break - at least in
case of the top 2000 PHP
packages. That's why I believe we can migrate them separately from the
primary ones, which are used
much more often.

 I wonder whether it was previously discussed to have all these converted
> objects implement a `Resource` interface and have `is_resource()` check for
> that.
>

Yes, the RFC links two threads about this topic:
https://externals.io/message/116127 and
https://externals.io/message/104361#104369. Even though
there's a clear interest in changing how is_resource() works, doing so
would bring us to a minefield...

Please could you add a separate vote for primary streams if the resource to
> object conversion should be done at all (requiring 2/3 votes to be
> accepted).

I will personally vote against this if there is no is_resource change as I
> think it's just too big BC break even for 9.0 - it will likely require
> massive update of many code bases.


Yes, I added the option.


> Both the function and maybe also the interface could then also be marked
> as deprecated, but it would allow for a much more painless transition.
>

While I would love to see resources go altogether, deprecating
is_resource() is way too early. Even if php-src itself manages to sunset
all the built-in resources,
there will still be lots of third party extensions which will still rely on
them.

Personally, I’m now relying on psalm to detect such issues, so if I had a
> vote I would selfishly vote yes anyways, but still: for those without
> static analysis,
>
this would IMHO make things much easier.
>

Yeah, using static analysis should be mandatory for mission critical
systems, since these tools can easily detect issues like wrong
is_resource() checks.
However, I acknowledge that doing so is not always possible due to some
constraints (i.e. budget limits). Fortunately, the possible issues
caused by resource
to object conversions are usually not too difficult to find out. For
example, in case of the Process resource, one has to search for all
proc_open() invocations, and
check whether the return values are correctly checked. According to my
experience, the is_resource() checks are usually very close to the creation
of resources, so
they can be fixed easily when needed.

Regards,
Máté

[PHP-DEV] PHP-8.1 open for bug fixes UNTIL 25 Nov

[Ben Ramsey]

NB: this is a reply to the other thread, with the subject changed.


On 11/10/23 13:57, Ben Ramsey wrote:

Hi, all!

According to the supported versions page[^1] (and our release process 
documentation), active support for PHP-8.1 ends on 25 Nov 2023. Since our 
release cycle has a release falling on 23 Nov, this means PHP 8.1.26 is the 
last bug-fix release for the 8.1 series. Following PHP 8.1.26, PHP 8.1 will be 
in security maintenance mode.

I know there was some confusion around this, and I apologize that we didn’t 
make this clear earlier (though the dates have been posted for a while ;-) ).

PHP 8.1.26RC1 was technically the last chance to get in bug fixes and have them 
tested prior to the release on 23 Nov.

Unfortunately, we’ve had a few bug fixes merged into the PHP-8.1 branch since 
yesterday, and I’ll work with Patrick and others on figuring out what to do 
with these.

Cheers,
Ben


[^1]: https://www.php.net/supported-versions.php



We’ve discussed this among release managers, and I’m updating this 
thread to clarify that I was mistaken about what the dates for supported 
versions mean. These are the dates up until we will accept patches to a 
version branch. So, for example, we will accept bug fix patches in the 
PHP-8.1 version branch until 25 November. This means there may be 
another release following the end-of-active-support date, if there are 
bug fixes in the version branch.


The PHP-8.1 branch is open for bug fixes UNTIL 25 November. I’m very 
sorry for the confusion.


Cheers,
Ben



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] Debian Upgrade

[Rowan Tommins]

On 21/11/2023 12:14, Derick Rethans wrote:

I have fixed this now.

It turned out to be a bug in *bugs.php.net*, which I had fixed
yesterday...



Wow, that was an unexpected chain of dependencies! Thanks for tracking 
it down. :)



Regards,

--
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Debian Upgrade

[Derick Rethans]

On Mon, 20 Nov 2023, Derick Rethans wrote:

> On 20 November 2023 21:37:55 GMT, Rowan Tommins  
> wrote:
> >On 15/11/2023 16:59, Derick Rethans wrote:
> >> In the last few days, I have upgrade all our Digital Ocean droplets from
> >> Debian 10 (or 9!) to 12. That also means they now run PHP 8.2.
> >
> >Thanks for getting things current! System maintenance is such an 
> >essential but often underappreciated task.
> >
> >I notice news.php.net (and therefore externals.io, which feeds from 
> >it) hasn't copied any message from the list since the day after you 
> >posted this (last timestamp is 16 Nov 2023 22:14:19 -). Could 
> >that be related somehow?
> >
> >Or if it's just coincidence, maybe you or someone else here knows 
> >which service might need prodding to bring it back to life?
> 
> Yes, this could be related. Somebody on the foundation slack raised it 
> too, so I'll have a look ASAP.

I have fixed this now.

It turned out to be a bug in *bugs.php.net*, which I had fixed 
yesterday:
https://github.com/php/web-bugs/commit/9ed00f752fb1f82a93ed08a13f45219e5723c0d0

Without this fix, emails sent to the bugs (and docs-bugs) mailinglists 
had very long "From" addresses.

Colobus, the tool that parses the mailinglists and creates the news 
interface and NNTP server, had a MySQL column defined for this to 
varchar(255). Usually enough, but it was now bailing out.

The "fix" was to change that column to "text" — not pretty, but better 
than hacking the mailinglist software's index.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news

mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug

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