Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert file_info resources to objects #5987

Closed
wants to merge 1 commit into from

Conversation

cmb69
Copy link
Contributor

@cmb69 cmb69 commented Aug 13, 2020

Besides our general desire to get rid of the legacy resource types,
this is particularly appealing for fileinfo, because there are already
respective objects.


Should probably inline php_fileinfo in finfo_object right away. Also, I wonder about serialization and cloning of finfo objects – is that properly supported?

@cmb69 cmb69 marked this pull request as draft August 13, 2020 23:59
@cmb69 cmb69 marked this pull request as ready for review August 14, 2020 07:42
@GrahamCampbell
Copy link
Contributor

GrahamCampbell commented Aug 14, 2020

// cc @frankdejonge Not sure if this affects you?

@cmb69
Copy link
Contributor Author

cmb69 commented Aug 14, 2020

If there are BC concerns, please say so! :)

@frankdejonge
Copy link

@GrahamCampbell If I see this correctly, this is only the function-style interface, the new finfo OOP-interface is unaffected, right?

@cmb69
Copy link
Contributor Author

cmb69 commented Aug 14, 2020

Indeed, the OOP interface is completely unaffected. The procedural interface now handles objects, so both could be mixed (which might provide a smoother upgrade path).

@frankdejonge
Copy link

Off-topic: if the fopen will become something other than resource in the future too, that would impact Flysystem. If there is something we can instanceof against, allowing us to be backwards compatible, that would be good to have in place.

@Girgias
Copy link
Member

Girgias commented Aug 14, 2020

Off-topic: if the fopen will become something other than resource in the future too, that would impact Flysystem. If there is something we can instanceof against, allowing us to be backwards compatible, that would be good to have in place.

The recommended way is to not check for an instanceof an object or use a is_resource() check but check against !== false. It is pretty likely that stream will change to objects as @sgolemon has been looking at this again.

@frankdejonge
Copy link

The recommended way is to not check for an instanceof an object or use a is_resource() check but check against !== false. It is pretty likely that stream will change to objects as @sgolemon has been looking at this again.

While that would work for the code that is opening a file-handle, it is not suitable for accepting one. For Flysystem, for example, the method accepts a resource opened elsewhere, so we need to have a way to check if it's the right input to prevent weird errors.

@Girgias
Copy link
Member

Girgias commented Aug 14, 2020

The recommended way is to not check for an instanceof an object or use a is_resource() check but check against !== false. It is pretty likely that stream will change to objects as @sgolemon has been looking at this again.

While that would work for the code that is opening a file-handle, it is not suitable for accepting one. For Flysystem, for example, the method accepts a resource opened elsewhere, so we need to have a way to check if it's the right input to prevent weird errors.

As the object does not yet exists (and won't before the conversion is done) the only way would to do a double condition, mind linking to the relevant code?

@frankdejonge
Copy link

@kocsismate
Copy link
Member

kocsismate commented Aug 14, 2020

@frankdejonge

While that would work for the code that is opening a file-handle, it is not suitable for accepting one. For Flysystem, for example, the method accepts a resource opened elsewhere, so we need to have a way to check if it's the right input to prevent weird errors.

You can add && !instanceof(finfo::class), can't you?

@frankdejonge
Copy link

@kocsismate that is correct, however, that was deemed not the best practice by @Girgias. Hence the further discussion. Perhaps we should take this discussion elsewhere since it's derailing the conversation (or preventing it even) about the current PR.

@cmb69
Copy link
Contributor Author

cmb69 commented Aug 14, 2020

I can't imagine that we switch stream resources to objects before PHP 9, so probably no need to discuss right now. :)

@cmb69
Copy link
Contributor Author

cmb69 commented Aug 21, 2020

If there are no objections, I'll merge this in a week.

@cmb69
Copy link
Contributor Author

cmb69 commented Aug 22, 2020

Nope, to late for this change for PHP 8.0.

@cmb69 cmb69 added this to the PHP 8.1 milestone Aug 22, 2020
@GrahamCampbell
Copy link
Contributor

Oh. Gonna be a shame to delay a lot of these changes till 8.1 when not strictly necessary. It will make things harder for library authors to make their code work on both PHP 8.0 and 8.1.

@cmb69
Copy link
Contributor Author

cmb69 commented Aug 22, 2020

Well, we're more than 2 weeks after feature freeze, and so such changes would make the upgrade to PHP 8.0 harder for users who already have started that process.

@GrahamCampbell
Copy link
Contributor

I suppose this has already been discussed and decided upon. ;)

@nikic
Copy link
Member

nikic commented Aug 24, 2020

Yeah, the release management decision here was to not do further resource -> object conversions past feature freeze. We don't stand a realistic chance of converting all resources to objects in PHP 8.0, some will necessarily happen later, so there's no strong motivation to allow them past feature freeze (unlike the warning -> Error conversions).

@nikic
Copy link
Member

nikic commented Oct 26, 2020

Also, I wonder about serialization and cloning of finfo objects – is that properly supported?

Cloning: Very, very no. Denied in PHP-7.3 via 7817fc0.
Serialization: No. Denied in PHP-8.0 via 6d3695a.

Besides our general desire to get rid of the legacy resource types,
this is particularly appealing for fileinfo, because there are already
respective objects.
@cmb69
Copy link
Contributor Author

cmb69 commented Dec 19, 2020

Any objections to merging this?

@php-pulls php-pulls closed this in b85f0d1 Dec 20, 2020
@cmb69 cmb69 deleted the cmb/finfo-objects branch December 20, 2020 17:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants